Fix threads stuck active after provider interruption

[luketraas]

Human comments

What was wrong

A provider can finish a root turn with status: "interrupted" without a user first requesting Stop. The server translated that completion to stop.settled, which is legal only from stopping. From active or starting, the lifecycle rejected the event and left the thread busy after its provider turn had ended. This was observed with Grok Build child threads after a rejected shell command: a parent could receive child-interrupted while a wait for the same child's idle status never returned. The captured server diagnostic was no transition for stop.settled from status active. The incompatible mapping and transition table are also present in the upstream base of this patch.

What changed

• Add run.interrupted as a terminal transition from starting, active, and stopping to idle, preserving the interrupted outcome and the separate manual-stop path.
• Apply root completion effects only to the latest stored root turn, so nested or superseded completions cannot settle a newer run or produce its parent notification.
• Wake already-queued messages on an applied transition to idle, including interruption. With no queued input, interruption does not retry the work.
• Add 9 real-server-route regression cases for the lifecycle states, duplicate delivery, nested turns, superseded completions, queued input, and child-to-parent notification. Update the generated lifecycle diagram and the existing lifecycle assertions.

No server/daemon wire field, protocol version, database migration, public API, or CLI change. This does not backfill already-stale records or change permission decisions.

Related: #3189 identified the queue-wake portion and was closed by the contributor approval gate. This patch also fixes the illegal lifecycle transition that prevents unsolicited provider interruptions from reaching idle, and guards against superseded root completions.

How you verified

• Before/after (original base c1a64f4b): ran the new regression file against the unchanged production files: 7 failed / 2 passed. Restored the patch and reran it: 9 passed / exit 0. The failing-before cases include unsolicited interruptions from active and starting, old-turn settlement, queued follow-up, and child settlement.
• Refreshed September 21: merged upstream 8e33492c into the branch without conflicts. The 7-file fix is unchanged. Rechecked the subsequent upstream text-utility change at 3275f6c6; it does not change the affected lifecycle/event handling.
• Fresh pnpm exec turbo run test --filter=@bb/domain --filter=@bb/db --filter=@bb/server --concurrency=1 --env-mode=loose -- --maxWorkers=2: domain 213 passed, database 590 passed, server 3062 passed / 1 skipped; 11 successful tasks / exit 0. Ran outside the sandbox with a temporary npm cache so plugin source-watch tests could execute normally. All 9 new regression cases are included in the server run.
• Fresh pnpm exec turbo run build typecheck lint --filter=@bb/server --filter=@bb/domain --concurrency=2: 7 successful build/typecheck tasks, 7 total / exit 0. These selected packages do not define separate lint tasks.
• Formatting check on all 7 changed files and git diff --check pass. A separate read-only review approved the patch after 2 minor fixes; a fresh review of compatibility with upstream's failed-queue retry policy also approved it with 0 findings.

The installed BB app was not patched, and no live provider turn was started or stopped to manufacture a reproduction. The regression tests use the real server event route and database-backed test harness.

AGENT GENERATED