Start a stopped session's process when a message is sent to it

Refusing was work handed back: read the status word, find the other
button, press it, type the message again. Sending plainly means "do this
now", and `--resume` puts the new process on the same conversation, so
nothing about the message changes -- only whether there was anything
there to read it.

`POST /sessions/{id}/message` now goes through the manager, which starts
a process first when the session is known to have exited. Only on
`exited`: `unknown` has a process that may well be reading its fifo, and
starting a second CLI on that guess is the fault `session::process`
exists to prevent, so the message goes to the driver as it always did.

The Start button and this ask one function, `start_if_exited`, and want
opposite answers from it -- "there is already a process" is a refusal
worth showing to somebody who pressed Start, and nothing at all to a
message being sent. Deciding it in one place under the one write lock is
also what keeps two requests that arrive together from starting two
CLIs.

Verified over the API and on the emulator: with the session reporting
`exited` and the composer showing a play button, typing a message and
pressing Send started the process, delivered the message and ran the
turn -- transcript order `idle`, `userMessage`, `running`, `idle` -- and
the button became a stop.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PLAN.md

@@ -375,6 +375,20 @@ Two rules come out of it, and neither is optional:
   existed for the backend going away — and it is the whole of what a driver
   whose process has exited is owed.
 
+**Sending a message starts the process if there isn't one** (decided
+2026-08-30). Refusing was work handed back: read the status word, find the
+other button, press it, type the message again. Sending plainly means "do
+this now", and `--resume` puts the new process on the same conversation, so
+nothing about the message changes — only whether there was anything there to
+read it. The manager's `send_message` and the Start button ask one function
+(`start_if_exited`) and want opposite answers from it: "there is already a
+process" is a refusal worth showing to somebody who pressed Start, and
+nothing at all to a message. Deciding it in one place under one write lock is
+also what stops two requests arriving together from starting two CLIs. Only
+`Exited` starts anything, for the reason above — `Unknown` has a process that
+may well be reading its fifo, and the message goes to the driver as it always
+did.
+
 The phone's half is that the process button is disabled while its own request
 is in flight, so a second press cannot be decided against a status the first
 one has not changed yet. That is a courtesy rather than the fix: the server