send-file: stream the body instead of buffering the whole file on both sides

[myobie]

Finding 7 of the 2026-08-29 review (reproduced: receiver peaked +1.0 GB, sender +1.0 GB on a 1 GiB transfer).

The hole

The sender read the file whole (std::fs::read in the daemon) and passed the slice to send; the receiver allocated vec![0u8; header.len] and read_exact into it. So a 1.5 GiB transfer held about 1.5 GiB of resident memory on each daemon at once. On a host with a MemoryMax, that is enough to kill the daemon mid-transfer, taking every shell, exec and sync session with it.

The fix

• Sender: send_file(stream, name, path) opens the file, reads its size from metadata, and send_from_reader streams exactly len bytes with tokio::io::copy over a bounded buffer. The daemon passes the path instead of std::fs::read-ing it.
• Receiver: streams the body straight to the temp file with the same bounded copy, reading exactly header.len bytes via take(len) so it never waits for an EOF the sender does not send before its ack.

Neither side allocates against the file size. The wire format is unchanged (header + len body bytes + ack), so a streaming build and an old build interoperate in either direction.

Tests

• a_large_file_streams_through_in_chunks: round-trips 5 MiB over a 64 KiB duplex (many chunks), bytes intact.
• a_short_stream_is_refused_and_leaves_no_file: a sender that promises 1000 bytes and sends 10 is refused, and no file (partial or final) reaches the inbox. This is a strict improvement — a short transfer previously errored on read_exact, now it is refused explicitly and cleans up.

The memory improvement is structural (no vec![0; len] on either side); the file that lands is byte-identical, so the unit tests prove correctness and the reviewer's two-daemon RSS measurement is the memory proof. cargo test green.