feat(agent-org): add post-completion read-only Coordinator turns for #635

[ShiboSheng]

Parent and dependency

• Parent issue: feat(agent-org): support post-completion chat and follow-up runs #635
• Depends on: feat(agent-org): add exact multi-run session ownership for #635 #642
• Delivery order: 2 of 5
• Intended PR: PR 2 — post-completion read-only Coordinator turns

Goal

Let users continue talking in the same Agent Org Conversation after a selected Run becomes completed, failed, cancelled, or abandoned, while keeping that Run and all historical Workers immutable.

A historical question must produce exactly one Root Coordinator turn. It must not write the old Run Inbox or wake the addressed historical Worker.

User behavior

• Selecting Run 1 and asking about Run 1 makes the Coordinator answer from Run 1 persisted Tasks, Plan, outputs, and member results.
• Historical @Reviewer or other member mentions are answered by the Coordinator from persisted evidence; the old Worker is never revived.
• If Run 10 is active while Run 1 is selected, a question about Run 1 remains read-only and does not steer or mutate Run 10.
• A request that requires new execution returns a structured Follow-up-required outcome; proposal persistence is delivered separately.

Required changes

• Extend the durable turn-intent contract with explicit mode and optional historical reference: ordinary, agent_org_run_work, and agent_org_post_completion plus reference_run_id.
• Route terminal Group Chat messages to the durable Root Coordinator transcript rather than the terminal Run Inbox.
• Add bounded selected-Run context: Run summary, Task summaries, output handles, Plan summary, and recent Conversation window. Load details only on demand.
• Apply a per-turn read-only tool policy at the execution boundary. Do not rely only on prompt instructions.
• Ensure historical read tools use the explicit reference_run_id, not whichever Run a cached runtime or parent walk considers newest.
• Return a structured follow_up_run_required product outcome for attempted historical mutation instead of a generic red tool error.
• Preserve ordinary active Run message routing and pause/resume behavior.

Invariants

• org_run_id continues to mean writable active Run ownership only.
• reference_run_id is read-only context and never grants mutation authority.
• The source Run, Tasks, Inbox, Sessions, interventions, completed_at, and Recovery budgets remain byte-for-byte or row-for-row unchanged after a question.
• No extra model call is made only to classify the message.
• Context rows and bytes are bounded.

Acceptance criteria

• Users can ask after Completed, Failed, Cancelled, and Abandoned.
• A normal historical question invokes one Coordinator turn and zero Worker turns.
• Historical member mentions do not wake old Workers.
• No row is inserted into the terminal Run Inbox.
• No source Run Task, Plan, intervention, session ownership, status, or Recovery budget changes.
• Selecting Run 1 while Run 10 is active does not steer or mutate Run 10.
• Historical mutation attempts return follow_up_run_required with the selected source Run id.
• Large Run and Conversation histories remain row and byte bounded.
• Existing Running and Paused group-chat paths do not regress.

Verification

• Unit tests for turn mode parsing, wire serialization, policy composition, and reference/write ownership mismatch.
• Database command tests proving no historical mutation and no old Inbox write.
• Runtime integration test proving exactly one Coordinator dispatch and no Worker Wake.
• Negative E2E assertions for hidden generic tool-error UI.
• Scoped Clippy, formatting, typecheck, lint, and architecture/performance guard review.

Out of scope

• Durable Follow-up proposal cards.
• Confirming or launching a new Run.
• Full Run timeline UI.

Estimated change size

• Roughly 8–14 files.
• Roughly 700–1,200 changed lines including tests.