# Does the main menu's cursor survive a REBOOT? ✅ NO -- MEASURED 2026-08-31.
#
# The main menu PERSISTS its cursor across menu -> title -> menu within one boot
# (focus-persists-across-title.txt). Whether it survives a reboot has been listed
# as untested since, and it decides whether "initial focus = NEW GAME" is a fresh
# -start value or merely what the last session happened to leave.
#
# NO NEW BOOT WAS SPENT. Six runs already captured the FIRST menu entry of a fresh
# boot (each `reach/1-F1.png`), read here with the calibrated ring reader:
#
#   run           ring y   first menu entry
#   focuspersist   225.5    NEW GAME
#   extrasfocus    225.5    NEW GAME
#   submenusweep   225.5    NEW GAME
#   submenu3       227.0    NEW GAME
#   submenu4       225.5    NEW GAME
#   difficulty     225.5    NEW GAME
#
# ✅ SIX INDEPENDENT FRESH BOOTS, ALL NEW GAME.
#
# 📌 AND THREE OF THEM FOLLOW A SESSION THAT ENDED ELSEWHERE, which is what makes
# this a test of persistence rather than a repeated observation:
#   22:06 extrasfocus  ended INSIDE EXTRAS        -> 22:17 submenusweep opened NEW GAME
#   22:17 submenusweep ended on OPTIONS           -> 00:42 submenu3     opened NEW GAME
#   01:21 submenu4     ended on OPTIONS           -> 01:46 difficulty   opened NEW GAME
#
# => Menu focus does NOT carry across a reboot. The port's authored NEW GAME is
#    correct for a fresh start, and is not an artefact of session history.
#
# ⚠️ REACH, and it is the important line: EVERY ONE of these sessions ends with the
# emulator being KILLED (ensure_single_emulator terminates the process). A game
# that writes menu state on a CLEAN shutdown would never get the chance, so this
# measures "does not survive a killed session", not "the game never saves focus".
# A clean-exit path is untested and this harness has no way to exercise one.
#
################################################################################
# INCIDENTAL, and it corrects a number of mine.
#
# The disc says the main menu's five buttons sit at design y 162 / 242 / 322 /
# 401 / 482 -- spacing 80 (examples/extras_button_order.rs).
# menu_focus.py's row centres are [166, 241, 315, 390, 465], spacing 75, drifting
# +4, -1, -7, -11, -17 against the real rows: over a QUARTER of a row by the
# bottom item. That drift is why the old reader was fragile.
#
# 🔴 So ring_row.py's stated calibration was wrong. It said
#     capture_y = 49.5 + 1.060 * design_y
# fitted against those approximate rows. Re-fitted against the DISC rows:
#     capture_y = 64.82 + 0.9919 * design_y     residuals all < 0.7 px
# The surface is offset ~65 px in the capture and essentially NOT scaled; the
# 1.060 was an artefact of the wrong reference.
# ⚠️ No item assignment changes -- ROW0 and SPACING are measured off captures
# directly and never used the bad fit.
