sprite file push/pull to a nonexistent sprite reports "directory <remote parent> does not exist" instead of a box-not-found error #203

Summary

When sprite file push targets a sprite name that does not exist, the CLI reports a filesystem error about the remote parent directory rather than a sprite-not-found error. This sent a production incident investigation down a long false trail (we probed base-image layout, boot races, and suspend behavior before discovering the target sprite had been destroyed by our own janitor process).

Repro (CLI on linux/amd64, authed)

$ echo probe > /tmp/probe.txt
$ sprite file push -s some-name-that-never-existed /tmp/probe.txt /home/sprite/x.tar
Error: directory /home/sprite does not exist
$ echo $?
1

Expected: something like Error: sprite "some-name-that-never-existed" not found (and ideally a distinct exit code from real remote-filesystem errors).

Actual: Error: directory /home/sprite does not exist — indistinguishable from the legitimate remote-parent-missing case (e.g. pushing to /tmp/..., which genuinely fails on a fresh sprite because tmpfs mounts after the parent-dir check — a quirk we design around).

Why it matters

We (collabd) run file transfers against sprites as part of a two-box sandbox pipeline and persist the CLI's stderr as the failure detail for triage. With this error shape, "the box was destroyed/never existed" and "the destination directory is missing on a live box" are the same string, so automated retry/recreate logic cannot distinguish a recoverable orchestration race from a real path bug.

Related earlier reports from the same integration: #201 (host-enforced --max-size for file pull), #202 (exec stdout byte drops on large streams).