Subtask dependencies in fan-out: run the plan as a pipeline

[liam-russell]

Problem

Real plans are rarely fully parallel — the API subtask must land before the UI subtask can build against it. Today (and even with fan-out #137) the planner or user must babysit ordering by hand: wait for A to merge, then manually spawn B off the updated orchestration branch.

Proposal

• Fan-out subtasks accept dependsOn (referencing sibling subtasks by name — same validation spirit as hook dependsOn).
• A dependent subtask's worktree isn't created until its dependencies merge into the orchestration branch (Orchestration worktrees: give the planner agent a checkout and a branch to integrate into #134) — so it branches off a base that already contains them.
• The stacked view (Stacked-work view: group workers under their orchestration branch, review merges, roll-up PR #136) shows pipeline states: queued → running → needs review → merged; a failed/discarded dependency pauses its dependents and raises an attention-inbox item (Attention inbox: one surface for everything that needs the human #146).
• The MCP fan-out tool (Wire SproutGit's MCP server into every integrated agent session #145) accepts the same field, so a planner agent can express the DAG directly.