Feature request: let a session start a new named session in the desktop app (spawn a peer, not a subagent)

Request. Add a tool that lets a Claude Code session start another full desktop-app session: a real peer with its own window, context, model choice, and permission settings — not an in-process subagent. The caller supplies a name, a working directory, and an initial prompt. The new session registers under that name so existing cross-session messaging (ListAgents / SendMessage) reaches it immediately. Gate the spawn behind a user permission prompt, the same way other side-effect tools are gated.

Why subagents and cross-session messaging are not enough. I run a multi-session review workflow on one shared repository: a long-lived "boss" session rules on escalations and gates merges, and several "dispatcher" sessions each own one branch, its worktree, and its adversarial review loops. The sessions already coordinate well by messaging each other. The one thing no session can do is create the next worker. Subagents do not fit this role: they live inside the parent's process, die with it, cannot be messaged by third sessions as durable peers across days, and share the parent's usage rather than appearing as an independent window I can watch and steer.

What the gap costs today, concretely:

1. Every new dispatcher requires me to manually open a window and type the launch naming step myself. The boss session can prepare the entire brief but must stop and wait for a human to click.
2. When a coordinating session dies overnight, the surviving session's only remedy is to send me an SMS asking me to restart it by hand. Unattended overnight work stalls until I wake up.
3. Manual launches cause name-collision and misdelivery bugs: two sessions registering the same messaging name, and assignments delivered to the wrong resumed session. A spawn tool that atomically registers the requested name would remove the whole failure class.

Suggested shape. SpawnSession({name, cwd, prompt, model?, permissionMode?}) → returns the session's messaging name/ref; the user approves each spawn in a dialog; the new window opens in the desktop app like any manually created session. A headless variant matters less — the visible window is part of the value, since I supervise these sessions directly.

Scope note. Cloud sessions and the claude CLI can already be started programmatically. This request is specifically about desktop-app windows that register a cross-session messaging name.