Promoting the measured 2052..2088 menu window in the TD2 SDL port

This checkpoint closes a useful gap in the SDL runtime: the menu_gameplay_entry rail no longer jumps from a handful of sampled post-2050 anchors. It now carries the exact measured baseline window from frames 2052..2088, and the default-rival A lane replays that same window with measured state mutations instead of guessed interpolation.

The practical change is in the scheduler and mutator surface. The runtime now loads every measured baseline frame in that bounded window from scheduler_rail_contracts.jsonc, and the A route mutator applies the traced state_09a2/state_09a8/state_137c plus dp_0020/dp_0022/dp_0053/dp_0054 values for the same corridor. That makes the menu rail much harder to drift silently: it is no longer “five anchors and some hope”, it is a concrete measured sequence.

The probe data justified that promotion. Inside 2054..2088, the no-input lane is stable enough to treat as exact contract data, while the A lane forms a real staircase: dp_0053/dp_0054 advance frame by frame, dp_0020 only flips on selected even frames, and state_09a8 only flips on part of the odd-frame cadence. That is exactly the kind of bounded, deterministic window that is worth promoting verbatim before trying to generalize anything.

Validation stayed clean after the expansion:

• scheduler smoke: 320/320
• input mutation smoke: 200/200
• compare lane: 3/3
• regression lane: 2/2

For design review, the runtime is still emitting PNG alongside the native PPM dumps, and this checkpoint also materialized a local paired A/B PNG pack for frames 2054, 2066, 2083, and 2088 so the team can track the corridor visually as the runtime evolves.

The next gate is straightforward now: stop hand-feeding this through --input-script only and wire live SDL keyboard/controller input into the same mutator path. The measured menu window is doing its job; the right next move is to make the runtime consume real input on top of it.