receive: store-write failure (e.g. ENOSPC) is reported as `error sending over irpc: Receiver closed`, hiding the real I/O error

Summary

When sendme receive runs out of space (or otherwise fails to write) into its on-disk store (.sendme-recv-<hash>/ in the current directory), the command fails with:

getting collection <hash> N files, X.XX GiB
error sending over irpc: Receiver closed
error: Receiver closed

The underlying cause - a failed write to the store (No space left on device) - is not shown. The message that surfaces is an internal irpc channel-closed error, which is very hard to diagnose from the outside.

Reproduction

sendme 0.36.0, linux-x86_64.

1. Start a sendme send <dir> of a multi-GiB directory on machine A.
2. On machine B, receive into a filesystem too small to hold the collection (a small tmpfs, a near-full partition, or - to force it deterministically - cap the writer: run with SIGXFSZ ignored and ulimit -f set below the largest blob).
3. The receive dies mid-download at the point the store filesystem fills, printing error sending over irpc: Receiver closed, exit code 1.

The transfer itself is fine - the same ticket receives completely into a filesystem with adequate free space. The failure is purely the local store write.

Expected

The error should name the real cause, e.g. failed to write to store <dir>: No space left on device (os error 28), so a user (or a tool wrapping sendme) can act on it. Right now the originating io::Error is swallowed behind the internal irpc "Receiver closed" message when the store actor drops.

Secondary ask

sendme receive has no flag to choose where the store/output lands (from receive --help: only --magic-ipv4-addr, --magic-ipv6-addr, --format, --relay, --show-secret, --jobs, --no-progress, --verbose). Callers must chdir to steer the .sendme-recv-* store onto a filesystem with room. An --out-dir / store-dir option would make this explicit. The README already notes the current-directory temp store is temporary ("In the future this won't be needed anymore.").

Environment

• sendme 0.36.0
• Linux x86_64

Start at the sendme receive path and the on-disk .sendme-recv-<hash>/ store, tracing the store actor's write error into the irpc result. Reproduce with a constrained filesystem or ulimit -f, then verify that the command reports the underlying I/O error; treat the --out-dir or store-dir request as separate scope if accepted.