[Juliusolsson05]

Summary

Adds the orchestration MCP domain on top of the built-in MCP host from #162.

An MCP-enabled parent agent can create real Agent Code child agents, send them prompts, and list the children it owns. These are normal visible Dispatch agents, not hidden subprocesses, so the user can inspect and manage the work while the parent agent coordinates it.

Closes #156.

Behavior

Adds three MCP tools under the orchestration domain:

• orchestration_create_agent — creates a Claude or Codex child agent in Dispatch, optionally with cwd, title, role, runId, initial prompt, and child builtInMcpDomains.
• orchestration_send_prompt — sends a follow-up prompt to an orchestration-created child session.
• orchestration_list_agents — lists this parent session's orchestration children, optionally filtered by runId.

Prompt submission uses bracketed paste, matching the composer path for long markdown-heavy prompts. For Claude, the sender waits briefly for the paste placeholder before submitting.

Design

Orchestration creation is split between main and renderer deliberately:

• Main owns MCP requests and provider PTY/session services.
• The renderer owns the workspace model: Dispatch placement, tab affinity, titles, persisted session metadata, and future multi-window behavior.

OrchestrationBridge therefore sends a typed orchestration:request IPC message to the renderer and waits for a typed response. The renderer creates/list agents through the existing workspace/session actions, so orchestration children are real Agent Code sessions in the same UI model as manually-created sessions.

Orchestration metadata is intentionally separate from linked-agent metadata. This PR adds orchestrationParentId, orchestrationRootId, orchestrationRunId, and orchestrationRole instead of reusing linkedParentId, because linked agents are a manual UI affordance while orchestration agents are programmatic workers with different lifecycle and future controls.

Files

• src/mcp/shared/orchestrationTypes.ts — typed orchestration requests/responses and agent records.
• src/main/orchestration/OrchestrationBridge.ts — main-to-renderer request bridge with timeout handling.
• src/main/ipc/orchestration.ts and src/preload/api/orchestration.ts — IPC surface for renderer orchestration responses.
• src/mcp/runtime/createBuiltInMcpServer.ts — registers the orchestration tools when the session scope includes orchestration.
• src/mcp/runtime/BuiltInMcpHttpHost.ts and src/main/index.ts — dependency wiring so MCP tools can reach SessionManager and OrchestrationBridge.
• src/renderer/src/workspace/hook/actions/pane.ts and src/renderer/src/workspace/hook/index.ts — renderer-side create/list implementation.
• src/renderer/src/workspace/types.ts — orchestration metadata fields on SessionMeta.

Verification

Live-exercised during development with the built-in MCP server enabled:

• orchestration_list_agents returned ok with the expected child list.
• orchestration_create_agent created visible Claude/Codex Dispatch child agents and returned their session ids.
• orchestration_send_prompt submitted follow-up prompts to those children.

tsc -b was attempted. The orchestration files typecheck, but the repo still reports unrelated pre-existing errors from submodule type resolution and renderer files outside this PR.

No test files added, per repo policy.

Test Plan

• Start an agent with builtInMcpDomains: ['orchestration'].
• Call orchestration_create_agent with a Claude child and initial prompt; confirm a visible Dispatch agent appears and receives the prompt.
• Call orchestration_create_agent with a Codex child and initial prompt; confirm the same.
• Call orchestration_list_agents; confirm only this parent's orchestration children are returned.
• Repeat list_agents with a runId filter.
• Call orchestration_send_prompt; confirm the target child receives the follow-up.
• Confirm ordinary linked-agent behavior is unchanged; orchestration metadata must not reuse linkedParentId.