Correct 04000000 finding: CheckRequest self-test leftover, not test mode

Bench refutation (display is static under axis movement; version-only
exchanges leave it alone) kills the A-9-E chord theory. Real mechanism:
the CheckRequest handler at $C5A6 runs a full self-test — sets the
test-display flag $2421, brackets itself with TestModeChange 0x8C,
lamp pattern, pod scan, five-channel encoder sweep — and returns
without repainting, leaving the channel-4 frame (04000000) as a stale
cosmetic snapshot. Board fully healthy; no reset needed. PROTOCOL.md
now warns hosts that 0x8C fires around every check. Candidate firmware
fix (repaint cave off $C5E4) noted for a future burn.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

RIOv4_2-ANALYSIS.md

@@ -498,13 +498,25 @@ sub-threshold teardowns — stock paints `E0…` at the first — and flipped
 exactly at the 5th teardown to **`E0000105`** (`$3187`=00 overflows,
 `$3184`=01 give-up, `$3185`=05 teardowns), confirmed by eye on the
 cockpit display. Mash regression (120s, lamps on,
-`testlogs/riomash-patched-e0t5-9600-20260719-154259.log`): **PASS** —
+`testlogs/riomash-patched-e0t5-9600-20260719-154259.log`): **PASS** �
 0 wedges, 236/236 presses, 88.0% analog fill, NAK 0, board counters
-flat. Incidental live finding: mid-mash the cockpit keypad delivered
-the A-9-E test-mode chord plus a `4`, dropping the board into axis
-test 4 (display `04000000`) — button scanning stops in test mode
-(mainline parks in the test loop) while the ISR-driven serial protocol
-keeps answering polls. Field-validates the display doc's test-mode map;
-exit is keypad `F` then `D`. The 31250v2_e0t5 image
-is the same patch on the certified FastRIO base and is expected to
-behave identically.
+flat. The 31250v2_e0t5 image is the same patch on the certified
+FastRIO base and is expected to behave identically.
+
+**Post-run display `04000000` — the CheckRequest self-test (corrected
+finding).** The first read of this (keypad A-9-E chord entering test
+mode) was wrong — disproved on the bench: the display is static (axis
+movement does not change it) and version-only exchanges leave it alone.
+The real mechanism is the **CheckRequest (`0x80`) handler at `$C5A6`**:
+a full built-in self-test that sets the test-display flag `$2421`
+(`$C5B1`), sends `TestModeChange 0x8C` to the host (`$C70E`), runs a
+lamp pattern (`$D34A`), scans the pods, sweeps all five encoder
+channels (`$CC53`, ending on channel 4 — whose `cc00hhll` frame is the
+last thing rendered), enqueues the fault reports, clears the flag
+(`$C5E1`), notifies `0x8C` again — and **returns without repainting the
+display**. Every status check therefore leaves a stale
+`04 00 <ch4 count>` snapshot (idle: `04000000`) on the digits. The
+board is fully healthy afterwards; no reset is needed. Proper fix, if
+the cosmetic bothers: a ~10-byte cave off `$C5E4` that repaints `F0`
+(`JSR $CB7C`) and re-renders the E0 readout when over threshold
+(`JSR $D5F2`) — candidate for the next burn, not yet built.