Mission exit, progress and map-state commit

The native exit path beginning 3EC8 now runs in a controlled fixture through its outcome branch, including the actual beacon-list commit C569 and map-state serializer BB90. Thirty cases cover normal/special selection branches, modes 0/1/2 and outcome bytes 1,2,3,4,FF.

Ordering

1. C569 applies the entire mission-header beacon queue to the current runtime map, before checking the outcome.
2. The path adds completed counter C21B to accumulator 3F24.
3. Record lookup 090B distinguishes normal selections 0–3 from special selection 4. It calculates an address and sets flags; it does not validate record contents.
4. With a normal selection and outcome 1, it increments the stage byte. For configurations below 4 it saves weapon-mask C88C, return-site C81E and the city-state stream selected by BC2D.
5. It then branches into next-stage setup, an outcome/presentation handler or general exit according to the outcome and lookup result.

The native comparison accepts values at or below 1 for advancement; fixtures use 1 because the surrounding main loop enters the exit path only for nonzero 3E9A. No gameplay meaning is assigned here to every other numeric outcome merely from its branch target.

In the fixtures, only normal-selection outcome 1 writes the city stream. Configuration 4 still advances the stage under that outcome but bypasses city-state serialization, matching the mode selector's exclusion of tunnels. A runtime beacon becoming zero during an unsuccessful exit is consequently not sufficient proof that its change is committed to the saved progression record.

The controlled map contains a type-1 beacon and a type-2 building. The exit list extinguishes the beacon; the actual serializer then writes the expected packed off/damage bits for successful city progression. Tests also check weapon-mask/return-site fields, accumulator updates and unchanged save areas for other branches.

Limits and reproduction

PYTHONPATH=/tmp/darker-python python3 tools/verify_mission_exit.py

Results cover 30 combinations. The normal/special selection result is substituted, along with audio/time/UI helpers 3533, A7E and AF52; actual exit branching, queue application and state packing execute. Tests stop at the destination, before running the next stage or outcome presentation. This is in-memory progression state, not a complete disk-save or death/reload test.

The real selection and reload follow-up replaces the earlier lookup substitution and establishes slot addresses, the special Nightmare entry and actual city reload behaviour.