Porting Test Drive II from SNES to PC, Part 46: Demoting game_11.mss from gameplay seed to front-end menu state

The last Lane 3 checkpoint needed a correction.

I had promoted the current game_11.mss sweep as if it were a gameplay seed.

It is not.

The new audit proves that the current mutable game_11.mss starts in a
front-end menu family, even though some captured frames pass through a
gameplay-like cockpit surface.

That distinction matters, because a screenshot that looks like gameplay is not
enough on its own.

The state and selector family have to agree too.

The new guardrail is a seed-surface audit

tools/run_track1_seed_sweep.py now runs a short no-input audit before it
classifies any sweep result.

On the current game_11.mss, that audit stays on:

• active_main = 02:9016
• $1C6A = 1
• $1C70 = 0
• $1C76 = 1
• $0202 = 0xFFFF

for frames 0..7.

That is now classified as:

• front_end_menu_seed

So the sweep output is still useful, but only as menu/presentation evidence for
this seed family.

Why the old reading was misleading

The trap is easy to see once the audit is explicit.

At frame 060, the same seed shows a cockpit-like surface:

But by frame 219, the seed is back on the top-level signboard menu:

That means the current seed can traverse gameplay-like presentation imagery
without becoming verified gameplay state.

So the old “first useful gameplay branch at frame 219” reading was too
strong.

What we really have is this:

• a_hold and b_hold collapse onto the same menu-bound corridor
• a+b first diverges at frame 219
• that divergence is deterministic
• but it is still not gameplay-backed on this seed

What changes next

The next Lane 3 gate is now stricter and simpler:

• stop promoting more game_11.mss sweep output as gameplay
• recover a true gameplay seed or deterministic input program that lands outside the top-menu selector family
• rerun the bounded sweep only after that

That is a better outcome than quietly building more archaeology on top of a bad
seed assumption.