Precommit one final candidate before exactly-once sealed-holdout promotion

[proerror77]

Parent

#580

What to build

Create one immutable final precommit after combination walk-forward and L2 replay pass, terminate the search, and then allow at most one sealed-holdout opening for that exact precommit.

Extend the existing sealed evaluation, bundle, and promotion lineage without creating a second governance path.

Acceptance criteria

• The final precommit binds Mission, snapshot/dataset/partition/source identities, Factor Bank, both baselines, MCTS checkpoint and subset, fixed weights, four-stage strategy, combination evidence, replay receipt/capabilities, evaluation protocol, and code/config identities.
• Only one unique final candidate can be precommitted for a Mission.
• Creating the precommit makes proposal generation, baseline fitting, MCTS transitions, strategy changes, and Mission resume terminally unavailable.
• Sealed-holdout access requires the exact valid precommit and rejects missing, drifted, or conflicting identities.
• Atomic same-payload retry returns the existing sealed receipt without rerunning evaluation.
• A conflicting or concurrent opening fails closed and cannot create a second valid receipt.
• Holdout-only mutation leaves every upstream semantic identity unchanged and can alter only the sealed result and its downstream promotion outcome.
• A passing holdout creates valid immutable StrategyBundle and PromotionRecord lineage bound to the precommit and sealed receipt.
• A failed holdout creates no promotion or deployable bundle.
• Sealed evidence cannot enter the active Mission's memory or search state.
• A later Mission influenced by exposed holdout evidence must bind a different unopened holdout identity.
• Tests cover retry, conflict, concurrency, post-precommit resume, holdout mutation, pass, and fail behavior.
• This issue does not activate Paper, Shadow, or LiveSmall.

Blocked by

#603