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>

PLAN.md

@@ -380,10 +380,18 @@ Two rules come out of it, and neither is optional:
 other button, press it, type the thing again. Both plainly mean "do this
 now", and `--resume` puts the new process on the same conversation, so
 nothing about what was typed changes — only whether there was anything there
-to read it. A rename is deliberately not one of them: it is persisted and
-listed whether or not a process ever hears about it, so starting a CLI to
-tell it a name would be spending a resume on nothing. The manager's
-`send_message` and `run_command` and the Start button ask one function
+to read it. A rename is included, and for a sharper reason than the rest:
+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, since every later start is a
+`--resume`. So a rename that reached no process would leave the two lists
+disagreeing permanently, with this app's the only one that had moved — and
+the cost of a resume buys the one thing renaming is for. It stays
+`rename_session` rather than becoming a command like the others, because the
+name is persisted and listed as well as forwarded and that is one operation;
+the save happens first, so a failure to start reports that the telling
+failed, not the rename. The manager's `send_message` and `run_command` 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