fix(coding-agent): trust supervisor-approved session renames in worker mode

[snimu]

What was wrong

Renaming a session could fail even though the rename was valid. In worker mode the supervisor already reserves and validates the new name, but the worker then validated it a second time against its own copy of the peer roster — which can be stale (sync failures are suppressed). So a name the supervisor had correctly approved could be rejected by the worker holding outdated data.

The fix

• Worker-mode command renames (rename, active rename_saved_session, set_session_name) now go through a mutation-only path: the supervisor's reservation is trusted, the worker just applies the name and appends the RLM ledger rename.
• Standalone daemons (no supervisor) keep the full local reservation + validation — nothing changes there.
• One regression test: with the worker-side validator stubbed to throw, a supervisor-forwarded rename succeeds and the validator is never called.

18 production lines, deletion-first (the second validation layer is gone, not worked around).

How it's verified

tsgo clean, biome clean, focused rename suites pass (daemon + supervisor), full-suite failures reproduce identically on main (pre-existing, unrelated). Implemented and independently reviewed by two different models; the reviewer traced all worker command paths and the authenticated-socket gate.

Follow-up candidates noted in review (not in this PR, same bug class, pre-existing): the non-active rename_saved_session branch and worker-mode create-with-name paths still double-validate.

Note: intentionally no Linear ticket for this cleanup stack, so that check stays red.

---

Note

Low Risk
Narrows worker rename behavior to trust supervisor authority; standalone validation is unchanged and scope is limited to session naming.

Overview
Worker-mode daemon renames no longer re-check name availability after the supervisor has already reserved the name. Commands rename, active-session rename_saved_session, and set_session_name now call setStateSessionNameForCommand, which in worker mode applies the name via applyStateSessionName (set name + RLM ledger) and skips setStateSessionName's reservation and assertStateSessionNameAvailable pass.

Standalone daemons (no worker option) still use the full setStateSessionName path. That path now delegates the actual mutation to shared applyStateSessionName after validation.

A regression test confirms a supervisor set_session_name succeeds when worker-side availability checks would fail, and that those checks are not invoked.

^{Reviewed by Cursor Bugbot for commit 1cb0f22. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Trust supervisor-approved session renames in worker mode and remove blanket RPC timeouts

• In worker mode, AgentDaemon.handleCommand now delegates rename, rename_saved_session, and set_session_name to a new setStateSessionNameForCommand helper that applies the supervisor-approved name directly via applyStateSessionName, bypassing availability validation. Outside worker mode, the previous validated path via setStateSessionName remains.
• Removes all fixed client-side timeouts from rpc.RpcClient (send, refine, waitForIdle, collectEvents). A new failPendingOperations helper centralizes rejection of in-flight requests and event waiters when the transport fails or the client stops. start now fails fast with stderr if the child cannot spawn, and stop proactively rejects pending operations before waiting for child close.
• Risk: rpc.RpcClient commands and agent completion waits no longer time out by default. A hung child process that keeps stdout open will leave pending operations waiting indefinitely until stop is called or the transport errors.

^{Macroscope summarized 1cb0f22.}

Linear: ENG-5648

[snimu]

Superseded by #1814: GitHub's stack lock prevents retargeting stacked PRs, so this PR was recreated as a plain PR against main (same branch, same content, all review threads here are resolved). Please review/merge #1814 instead.