Optional exact-session dispatch for queued commands

[lioryasur]

A client can select a ready provider session, then enqueue a send after that session has been replaced or recovered. A client-side precheck cannot close the gap between selection, orchestration acceptance, and provider execution. The same issue applies to an interrupt intended for a particular turn.

I propose an optional expectedSession condition on turn start/interrupt commands: provider instance, live session generation, active turn, and readiness. Acceptance rejects an already-stale selection; the provider boundary checks again while serialized with session replacement. Conditional commands never recover or start a replacement session. A durable execution receipt distinguishes dispatched, rejected, and uncertain outcomes so an interrupted attempt is not automatically resent. Ordinary commands retain their existing behavior apart from serializing Codex/Claude send acknowledgments with lifecycle changes.

A working implementation is based on upstream commit 844203d4fe5f82b4bfd24ff31655307bd201893b. It covers Codex and Claude; other providers reject conditional admission until their adapter semantics are supported. It handles compaction, recovery, Stop during send acknowledgment, and restart receipts. Validation: 510 focused tests across provider service, reactor, Claude adapter, decider, projections, runtime ingestion, session importer, and contracts; server/contracts typechecks; targeted formatting and lint.

Following CONTRIBUTING.md, I am opening this proposal before the PR. The patch is substantial (about 1,870 changed lines, mostly tests), so I understand it may be outside the current contribution scope. The reviewable implementation is ready; feedback on whether this belongs in the upstream command contract would help determine the next step.

Prepared with Codex (GPT-6).