# Do LOAD GAME, TUTORIAL and OPTIONS remember their cursors? ✅ NO -- ALL RESET.
# MEASURED 2026-08-31, one boot, fourth attempt.
#
# The main menu PERSISTS its cursor across menu -> title -> menu
# (focus-persists-across-title.txt). EXTRAS RESETS (extras-focus-resets.txt).
# Two screens disagreeing means no menu-wide rule and every screen must be
# measured. These are the three that were left. ❔ NEW GAME stays deliberately
# untested -- it starts a game.
#
#   LOAD GAME   RESETS   in-cursor 21.6 from opened vs  86.3 from where left
#   TUTORIAL    RESETS   in-cursor  2.3 from opened vs 113.2 from where left
#   OPTIONS     RESETS   in-cursor  1.9 from opened vs 102.6 from where left
#
# ✅ SO: FOUR OF FOUR MEASURED SUBMENUS RESET. Only the MAIN MENU persists, and
# it is the exception rather than the rule.
#
################################################################################
# WHY THIS RUN WORKED WHERE THREE DID NOT -- every control here is a previous
# failure:
#
#  * DECISION ON THE CURSOR'S OWN REGION. The pixels that change when the cursor
#    moves ARE the cursor, so no per-screen geometry is assumed. Sweep 1 voided
#    all three because ring_row.py scans the MAIN MENU's gutter (x 500:542) and
#    these screens put their cursors at x 97..231, 338..1099 and 153..479 -- it
#    was reading a static element and reporting no motion.
#  * NARROW back-on-the-menu test, by ring row. Sweep 2 died when a crash dialog
#    covered the screen centre: a whole-frame identity test can never match again
#    once anything overlays the frame, while the narrow column kept reading.
#  * ABSOLUTE row check after EVERY navigation press, not just the total -- a
#    constant offset passes a differential control exactly, which is how an
#    earlier run walked to OPTIONS believing it was EXTRAS.
#  * A TWO-SIDED SELF-TEST that constructs BOTH verdicts from known frames and
#    exits 3 if either is wrong. It passed here; it had already caught a rule I
#    broke myself in sweep 3, which would otherwise have reported RESETS for all
#    three screens -- the same answer, fabricated.
#  * Every press confirmed from the guest's own [RE-INPUT] log.
#  * The tool COMMITTED BEFORE RUNNING, and nothing else run during the boot.
#
# ✅ AND THE SCREENS ARE CONFIRMED BY EYE, because a previous run was fooled about
# which screen it was on:
#   captures/menu-nav/live-tutorial-submenu.png  -- TUTORIAL: BASIC CONTROLS /
#     HEADS-UP DISPLAY / RADAR under "Level 1", SUPPLY AND SPECIAL MOVES / RADIO
#     ORDERS / ADVANCED CONTROLS under "Level 2", then BACK. Seven items in two
#     groups, with a description panel on the left.
#   captures/menu-nav/live-load-game-slots.png   -- LOAD GAME: a SCROLLING slot
#     list with the selection held at the vertical CENTRE, Details panel at right.
#
# 📌 LOAD GAME's 21.6 is the one number that is not near zero, and the capture
# explains it: the list SCROLLS rather than moving a ring, so a DOWN redraws the
# whole list and re-entry restores the scroll position rather than a cursor sprite.
# 4x separation, same verdict, different mechanism.
#
# ❔ STILL NOT SEPARATED: "resets to the named item" vs "resets to the TOP item".
# sylpheed-port asked for a submenu whose opening item is not its first, which
# would decide it. None of these is one. TUTORIAL opens on BASIC CONTROLS (first),
# OPTIONS on GAME SETTINGS (first), and LOAD GAME on slot 01 -- which LOOKS
# non-first because slots 19 and 20 are drawn above it, but that is the list
# wrapping around a centred selection, and 01 is still the first slot.
#
# ⚠️ REACH: one boot, one round trip per screen, one direction (DOWN), and one
# entry each. Not tested: a second re-entry, a reset after a reboot, or whether
# any submenu behaves differently when entered from a different parent focus.