Start the process for a rename too -- the CLI keeps its own name

The last commit left renaming out on the grounds that the name is
persisted and listed whether or not a process hears about it. That was
wrong, and Iris said so: Claude Code keeps its own copy of the name,
that copy is what its session picker shows and what other agents read
when they list sessions, and a session is only ever *given* a name at
birth -- every later start is a `--resume`, which passes no `--name`.
So a rename that reached no process left the two lists disagreeing
permanently, with this app's the only one that had moved. The cost of a
resume buys the one thing renaming is for.

It stays `rename_session` rather than becoming a command like the rest,
because the name is persisted and listed as well as forwarded and that
is one operation. The save happens first and the lock is dropped before
the telling, so a failure to start reports that the telling failed
rather than the rename, which by then has already happened.

`LiveSession::run_command` went with it. It read `shared.status` and
that read is exactly what a just-started session cannot be judged by, so
every caller now goes through the manager -- which is also what the four
tests that used it were standing in for.

Verified against a stand-in CLI that echoes its stdin: a session
reporting `exited` was renamed, the process started with `--resume`, and
the CLI received `/rename after the restart` on stdin. The list shows
the new name and the session reports idle.

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

AGENTS.md

@@ -296,10 +296,15 @@ day:
   `SessionManager::send_message` and `::run_command`, which start a process
   first when the session is known to have exited and then hand the thing to
   the driver that has one behind it. Only on `exited`: `unknown` has a
-  process that may well be reading its fifo. `/rename` is the exception —
-  the name is persisted and listed either way, so it is forwarded to a
-  process that happens to be there and never starts one. So the Start button
-  is for when you want a process and nothing to say to it yet.
+  process that may well be reading its fifo. `/rename` starts one too, and
+  for a sharper reason than the rest: the CLI keeps its own copy of the
+  name, that copy is what its session picker and other agents' session
+  lists show, and a session is only ever *given* a name at birth — every
+  later start is a `--resume` — so a rename that reached no process would
+  leave the two lists disagreeing for good. Its save happens before the
+  telling, so a failure there says the telling failed rather than the
+  rename. So the Start button is for when you want a process and nothing to
+  say to it yet.
 - **Each session directory now holds `process.json`, `stdin.fifo`,
   `stdout.log` and `stderr.log`.** `stdout.log` is the driver's input, read
   from the byte offset in `process.json`; removing either by hand while the