Answer the "how do we test SSH here" question by testing it

The status section had carried an open question since phase 3: SSH could
not be exercised in this VM because there is no second machine and no key
in ~/.ssh. There is a second machine, though -- this one. Ssh it to itself
with a throwaway key and a host of bob@127.0.0.1, point the provider's
command at /bin/echo rather than claude, and the whole path runs:
connection, remote exec, and the process's death arriving as
`status: exited` in the transcript. It costs no tokens and touches nothing
real, and the key comes back out afterwards.

Done that way just now against the new transport, so the technique is
written down as something that worked rather than something that should.

Also recorded: the login shell in this VM is fish. `cd '…' && exec '…'`
is valid there and the POSIX single-quote escaping happens to mean the
same thing, but both are luck, and a non-POSIX remote shell is the first
thing to suspect if an argument is ever mangled on the way over.

Phase 4 is no longer deferred -- Bryan asked for llama.cpp today -- so the
status paragraph stops saying it is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xn8nHw1tw1R6PtiY1eEtw

AGENTS.md

@@ -57,11 +57,35 @@ repo is in PLAN.md's "Backend layout" section.
 Phases 1–3 done 2026-08-24 (see PLAN.md's phase list for what each
 verified): the skeleton pipe, the full Claude driver (streaming, tools,
 permission + AskUserQuestion cards, steering, interrupt, `--resume`
-crash recovery, images both ways), and the usage screen. Phase 4
-(pi/llama.cpp) is deferred — not testable in this VM. Next: phase 5
-(SSH; needs a decision on how to test — no keys in `~/.ssh` here) and
+crash recovery, images both ways), and the usage screen.
+
+**Phase 5 (SSH) is written and now exercised** (2026-08-28). A session
+names a host, `session::transport` turns that into an `ssh host …`
+invocation, and the driver never learns which it got. Phase 4 (llama.cpp)
+is being built now, no longer deferred. What is left is
 real-phone/WireGuard bring-up, which is operational rather than code.
 
+**How to test SSH here, since there is no second machine:** ssh this VM to
+itself. Generate a throwaway key, append the public half to
+`~/.ssh/authorized_keys`, and configure a host of `bob@127.0.0.1` with
+`identityFile` pointing at it plus
+`options: ["StrictHostKeyChecking=no", "UserKnownHostsFile=…"]` so it
+touches nothing real. Point a provider's `command` at something harmless
+like `/bin/echo` rather than at `claude`: the transport is what is under
+test, the process exiting immediately is the signal, and it costs no
+tokens. A session spawned on that host logs `running /bin/echo on loopback
+(bob@127.0.0.1)` and lands `status: exited` in its transcript, which is
+the whole path — connection, remote exec, process death reported. **Take
+the key back out afterwards**; this VM's `authorized_keys` is not scratch
+space.
+
+Note the remote login shell here is **fish**, not a POSIX shell. The
+remote script (`cd '…' && exec '…'`) happens to be valid in both, and the
+POSIX single-quote escaping `ssh.rs` does happens to mean the same thing
+in fish — but that is luck rather than design, and a shell that isn't
+either would be the thing to suspect first if a remote spawn ever
+mangles an argument.
+
 ## Checking your work
 
 - Server: from `server/`, `./run-tests.sh` (or `cargo test`) +