[FEATURE] Desktop: plan session sees status of tasks spawned via chips (orchestrator view)

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

When I work on a big implementation, I plan it in one Code-tab session and want each task executed in a fresh, clean-context session. The desktop app already supports the first step: Claude can create a "Suggested task" chip via spawn_task, and clicking it starts a new session with the prepared prompt in its own worktree.

The problem starts right after the click. The planning session has no idea what happened to the tasks it suggested. It cannot tell which chips were started, which are running, which are waiting for my input, which finished or failed. Neither can I, without opening every child session one by one. So the "plan" session stops being useful as the place where I manage the work — I end up tracking statuses manually in a notes file, which defeats the point of having the plan and the tasks linked.

Proposed Solution

Keep chips as the way to spawn a fresh session, but make the relationship parent → child visible and queryable:

1. Each chip rendered in the planning session shows a live status: not started / running / needs input / done / failed, plus a link that opens the child session.
2. When a child session finishes, its final summary (or a short tldr it writes back) is delivered to the parent session as a tool result / message, so the parent can update the plan and suggest the next task.
3. The ccd_session MCP server exposes read-only tools to the parent, e.g. list_spawned_tasks() and get_task_status(task_id), so Claude in the plan session can answer "what's the state of the plan?" and re-render a status table on request.
4. Optional: "Start all remaining" / "Start next" on a group of chips, so a plan with 10 tasks doesn't need 10 separate clicks — still user-initiated, so no autonomous spawning.

Alternative Solutions

• Subagents (Agent tool): output flows back into the parent, but they share the parent's context budget and I can't open/steer them as real sessions.
• Manually starting new sessions and pasting a prompt: works, but the plan session loses track of them entirely.
• A shared PLAN.md / TODO file the child sessions update: fragile (needs every child to be told to update it, conflicts between worktrees) and the parent still has to re-read it and doesn't know when a child is done.
• #94697 asks for programmatic spawning; #53494 reports spawned tasks being undiscoverable. This request is about the missing feedback loop to the parent, not about removing the click.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

1. In session A I describe a feature; Claude produces a plan with 6 tasks and suggests each as a chip with a self-contained prompt.
2. I click tasks 1–3. Each starts in its own fresh session/worktree.
3. Back in session A, the chips show running. Task 2 hits a design question → chip shows needs input, I click through, answer, come back.
4. Task 1 finishes; its summary appears in session A. I ask Claude "update the plan and give me the current status table" — it does, from list_spawned_tasks, without me pasting anything.
5. I click tasks 4–6, repeat. Session A remains the single place where the whole implementation is tracked.

Additional Context

• Related: #53494 (spawned tasks invisible / no task_id), #94697 (programmatic session start), #95190 (model/effort per chip).
• Each child session should stay a normal session in the sidebar; the parent only needs a read/notification channel, not control over the child's context.
• Chip suggestions should remain explicitly user-initiated, which addresses the concern raised in #80238.

Start by tracing the existing spawn_task flow, Suggested task chips, child sessions, and the ccd_session MCP server described in the issue. Define how parent-child relationships and statuses are represented, then verify that chips expose task state and child links, completed summaries reach the parent, and read-only status queries work.