fix(server): a steered send no longer leaves a subagent task running#19019

Problem

t3_thread_send into a delegated child records a follow-up task on the parent (recordSubagentFollowup in Orchestrator.ts) and binds it to the child run that received the message. When the send steers into a running child run that has no task of its own, the binding is written mid-run. The run's terminal write in RunExecutionService.ts starts from the run snapshot taken when its attempt started, so the binding is gone once the run ends. No terminal run matches the task, and the parent row stays running: the composer keeps "Waiting on subagent", and Stop and task_cancel cannot clear it.

Runs without a task of their own include those started by a notification wake, a scheduled task, a restart continuation, or a follow-up sent before the original result was published. A steer into a run that already has a task returns that task and creates nothing, so the triage's "absorbing run keeps its earlier delegatedTaskId" case is not where the stuck row comes from.

Change

recordSubagentFollowup gives a send its own task only when the same command created a run or a new attempt. A steer that joins the running attempt gets no task.

Contract: a steer into a running turn that already has a task still returns that task's id. A steer into a running turn with no task now returns delivery: "steered" without a taskId, instead of a task that never settles. A send that restarts a turn with no task, including the automatic restart fallback that also reports delivery: "steered", still gets its own task, and the restarted run keeps it to the end. The t3_thread_send tool description now says which sends return a taskId.

Carrying a mid-run binding through the terminal write instead would change which fields that write takes from the live run. Its comment covers only delegatedCompletion, and widening it is more change than this bug needs.

Surface: the parent composer's "Waiting on subagent" chip, which renders the server's subagent rows. No UI code changes.

Scope and approval

Refs #19002. Maintainer triage confirmed the bug in this comment. This stops new steered sends from leaving a row behind. It does not make Stop clear rows that are already stuck, because Stop has no settlement write today.

Verification

Box check on Ubuntu 24.04, head 845975728a, base 6524a8d437:

• 69 tests pass in apps/server/src/mcp/OrchestratorMcpService.test.ts, apps/server/src/mcp/OrchestratorMcpToolkit.integration.test.ts, apps/server/src/mcp/toolkits/orchestrator/tools.test.ts, apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.ts, apps/server/src/orchestration-v2/ProjectionRecovery.test.ts, apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts.
• With apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/mcp/toolkits/orchestrator/tools.ts reverted to 6524a8d437, 1 test fails with assertion errors: "orchestrator MCP toolkit > delegates cross-provider tasks, polls and cancels children, and creates ordinary threads".
• vp fmt --check and vp lint report no errors and no new warnings on the 3 changed TS files.
• Typecheck passes for t3.

The toolkit test delegates a Claude child, starts a server-sent run on it, steers into that run with t3_thread_send, waits until the fake provider receives the steer, then ends the run. On main the send returned a task id, the run carried it until it ended and lost it after, and the parent row stayed running (3 of 3 runs). The control is a Codex session with active steering turned off: the send restarts the turn, gets a task, the run keeps it, and the task settles as completed. The test ends the steered run with an interrupt because the fake provider holds that turn open.

Model: Claude Opus 5.5, Claude Fable 5.1 (review), GPT-6-Astra (review). Harness: Claude Code, Codex.