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>

server/src/routes.rs

@@ -841,10 +841,14 @@ async fn command(
         Some((name, rest)) => (name, rest.trim()),
         None => (text, ""),
     };
-    // Everything but a rename goes through the manager, which starts the
-    // session's process first if it has exited. A rename is persisted and
-    // listed whether or not a process hears about it, so it neither needs
-    // one nor is worth starting one for.
+    // All of these start the session's process first if it has exited: a
+    // command is something somebody asked the session to do, and answering
+    // that its process is gone hands back the work of starting one.
+    //
+    // A rename still goes through `rename_session` rather than being a
+    // command like the rest, because the name is persisted and listed as
+    // well as forwarded, and that is one operation. It starts a process
+    // too, and for a sharper reason than the others -- see there.
     let command = match (name, rest) {
         ("/compact", _) => SessionCommand::Compact,
         ("/clear", _) => SessionCommand::Clear,