feat(agent-org): add exact multi-run session ownership for #635

[ShiboSheng]

Parent

• Parent issue: feat(agent-org): support post-completion chat and follow-up runs #635
• Delivery order: 1 of 5
• Intended PR: PR 1 — exact Conversation/Run/Session ownership foundation

Goal

Establish the persistence and resolver invariants required for one Root Coordinator Conversation to own several sequential Agent Org Runs without allowing an old Worker Session to resolve to a newer Run.

This issue changes foundations only. It must not yet expose Follow-up launch UI or allow a second Run to be created from the Conversation.

Required changes

• Add Run lineage and idempotency fields equivalent to continued_from_run_id and originating_message_id.
• Add canonical agent_org_run_sessions ownership for coordinator and worker sessions.
• Permit the Root Coordinator Session to appear in multiple sequential Run mappings; permit every Worker Session to belong to exactly one Run.
• Backfill legacy coordinator ownership and only unambiguous Worker ownership. Detect ambiguous or duplicate live legacy data and report it; never silently terminalize or reassign user data.
• Add the database invariant for at most one live Run per Conversation, covering starting, running, and paused once starting is introduced.
• Change resolution precedence to: active turn intent ownership, exact Run/Session mapping, the one live or explicitly selected historical Run for the Root Coordinator, then bounded parent-walk only as legacy fallback.
• Update delete/read helpers that currently assume one Root Session can own only one Run so later Follow-up creation cannot corrupt or reject a valid multi-Run Conversation.
• Add a bounded keyset-paged backend Run timeline/read API for later UI use.

Invariants

• Terminal Runs stay terminal and retain completed_at.
• An exact mapping always wins over parent walking.
• Opening an old Worker always resolves its historical Run, never the newest Run under the same Root.
• No unbounded ancestry or Run-history scan is introduced.
• Existing single-Run Conversations continue to work without user action.

Acceptance criteria

• A Root Coordinator Session can be mapped to Run 1 and Run 2 sequentially.
• A Worker from Run 1 still resolves Run 1 after Run 2 exists.
• A Worker cannot be mapped to two Runs.
• Two live Runs for one Conversation are rejected transactionally.
• Duplicate or ambiguous legacy live Runs are detected and reported without silent mutation.
• Legacy single-Run roots and unambiguous Workers are backfilled idempotently.
• Timeline reads are keyset-paged and row bounded.
• Existing Run View, Wake, Recovery, Approval, Pause/Resume, Finality, and terminal group-message rejection do not regress.

Verification

• Rust/database migration and resolver tests, including legacy, duplicate, cycle, stale-parent, exact-mapping precedence, and repeated-init cases.
• Existing Agent Org lifecycle and deletion suites.
• Scoped Clippy and formatting.
• Architecture audit covering domain types, ownership, state machines, persistence, wire shape, resolution symmetry, and compatibility.

Out of scope

• Post-completion Coordinator turns.
• Follow-up proposal creation.
• Creating or starting a Follow-up Run.
• User-visible Run selector or proposal card.

Estimated change size

• Roughly 10–16 files.
• Roughly 900–1,500 changed lines including tests.
• Re-estimate the remaining child issues after this persistence shape is implemented.