Files Changed: gate migration and coordinated release

Acceptance Criteria

• Capability discovery deterministically selects full, post-upgrade-partial, or legacy mode without probing a mutation route.
• Old engine with new client and new engine with old client remain safe and visibly labelled.
• Pre-existing sessions remain legacy; an active old session can record only a labelled post-upgrade epoch.
• In-flight v1 reservations are resolved as legacy and never silently adopted into a ledger operation.
• Rollback from a partially deployed release cannot authorize an uncontextualized full-provenance mutation.
• Fork release completes before the verified vendored-binary pin, which completes before extension release; overlay synchronization is verified as release evidence.
• Default enablement remains off until the adversarial acceptance matrix succeeds.

Testing Decisions

• Add capability and mixed-version contract tests across supported engine and extension combinations.
• Exercise upgrade, rollback, active-session, and in-flight-reservation fixtures in release rehearsal.

Key Decisions

• Compatibility discovery is separate from mutation-context validation.
• Overlay synchronization demonstrates source provenance; it does not substitute for a binary protocol release.

Constraints & Invariants

• Legacy mode may preserve prior behavior but never claims full provenance.
• Release ordering cannot be collapsed into a client-only deployment.

Prior Art

• Parent Files Changed: full session-lineage mutation ledger #972
• Existing Files Changed: session-bind Sidebar external file mutations #976 release and binary-pin gate

Deliberation Resolution

• Capability discovery returns a versioned object with protocol_version, mode, and migration_boundary. mode is full only for a supported engine and a session born after rollout; partial applies to an opted-in post-upgrade epoch; legacy covers unsupported engines and pre-existing sessions without an epoch.
• The supported matrix is explicit: old engine plus new client is legacy; new engine plus old client keeps its pre-ledger view; new engine plus new client is full only for a full root; new engine plus new client on a partial or legacy root remains labelled partial or legacy.
• Migration transitions are legacy -> partial only through an explicit epoch start, never by background inference. In-flight v1 reservations resolve as legacy results. Rollback disables full discovery before client mutation routes are available.
• The release manifest lists required fork tag, binary checksums, lock pin, extension version, overlay provenance check, rehearsal cases, and mandatory matrix case IDs. Default enablement requires a machine-readable all-required-passed result.

Source

Part of #972. Blocked by #976 and #1082.