Stream attachments end to end, ship files to a remote session's machine, and write up the transcript work

Uploads no longer sit whole in memory anywhere: the phone writes the
multipart body chunked as it reads the picked file, and the server writes
each chunk to a `.part` file under the session and renames it when whole.
The per-request cap is 4 GB and bounds disk, not memory.

A file attached to a session on another machine is copied there in the
same request: one ssh invocation takes the bytes on stdin into the
setup's `attachmentsDir` (new, optional, on the machine form and in the
config), else the session's cwd, else the login home, and answers with
`pwd -P`, which is recorded beside the file as `<name>.remote` and is the
path the driver tells the CLI. A failed copy fails the upload and says
why, so no message ever names a file that is not there. The host keeps
its copy so transcripts can reference and fetch it. Measured against the
Gentoo test guest: a 40 MB file shared from the phone arrived there byte
for byte. The tilde in that setting is the remote home, so it is not
expanded on the server the way other setup paths are.

TRANSCRIPT_RENDERING.md records the week of transcript work -- the
measurements behind each decision, the harness, what was rejected, and
what to do next -- so a new session can start from it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

PLAN.md

@@ -720,11 +720,17 @@ host) and **hosts**. The manager runs at most one llama-server per
   remote filesystem, so there is no `scp` step to get wrong.
 - **Any other file is told to the session by path** (2026-09-03: a trace,
   a log, a zip -- things a model cannot be shown and the CLI can read).
-  The upload stays under the session's `attachments/` and the message
-  ends with `Attached file: /abs/path`. That directory exists only on the
-  machine running this server, so a file attached to a remote (ssh)
-  session names a path that is not there. Shipping it is not built; the
-  one host in use runs its sessions locally. Images are unaffected.
+  The upload is streamed to disk under the session's `attachments/` on
+  this machine -- the transcript references it there and the phone can
+  fetch it -- and the message ends with `Attached file: /abs/path`. For a
+  session on another machine the upload also copies the file there, in
+  the same request, over one `ssh` invocation (`cat` from stdin, then
+  `pwd -P` so the answer is the absolute path the CLI is told). It lands
+  in the setup's `attachmentsDir` if set, else the session's cwd, else
+  the login home; the resolved remote path is recorded beside the file
+  (`<name>.remote`) and is what the driver names. A copy that fails fails
+  the upload, so no message ever names a file that is not there. Images
+  are unaffected: they ride the message as base64.
 
 ### Usage limits (Claude)
 
@@ -1103,10 +1109,9 @@ window just fills.
    command is the identical one wrapped in `ssh -T`, with every argument
    shell-quoted). Attachment shipping turned out to be unnecessary for
    images — they ride the stdio JSONL as base64 in both directions, so
-   nothing needs `scp` — and became necessary again on 2026-09-03 for
-   files, which are attached by path (see "Transport" above). Still
-   outstanding: file shipping for remote sessions, and remote
-   llama-server with its port forward, which comes with phase 4.
+   nothing needs `scp` — and was built on 2026-09-03 for files, which
+   are attached by path (see "Transport" above). Still outstanding:
+   remote llama-server with its port forward, which comes with phase 4.
    Two things learned doing it: a remote session inherits ssh's non-login
    PATH, which is narrower than an interactive shell's (point `command` at
    an absolute path if a CLI isn't found), and the remote command is run