# Does the main menu REMEMBER its cursor across menu -> title -> menu?
# MEASURED 2026-08-30. Answer: YES.
#
# WHY IT MATTERS: menu-navigation-semantics.md records initial focus as TUTORIAL
# (2/2 boots) while boot_menu.sh's closing line says NEW GAME and
# menu-state-in-memory.md reaches EXTRAS in four downs, which only counts from
# NEW GAME. If focus PERSISTS, then any "initial focus" reading not taken on a
# fresh boot's FIRST menu entry is measuring history, not initial focus -- which
# would explain the disagreement without any of the records being wrong.
#
# HARNESS: tools/re-capture/focus_persistence.py, on the path b_from_menu.py
# validated -- plate-pulse title detector, glyph-327 menu detector, and every
# press confirmed from the guest's own [RE-INPUT] log rather than from the pad.
# NOT boot_menu.sh: its title gate tests for stillness and this title never
# stills (harness-title-gate-assumes-a-static-title.md). The plate-pulse gate
# reached TITLE at 422.7 s on the boot skip_intro could not gate at all.
#
# ✅ CONTROL, and it is the reason run 1 is discarded rather than reported:
#    two DOWN presses must move the cursor exactly two items. If they do not,
#    the reader is not tracking and F3 may not be read.
#
#   [   1.0s] MENU (glyph 327)  F1 = TUTORIAL   ring   130    76   254    69    64
#   [   7.3s] DOWN delivered (attempt 1)
#   [   8.2s] DOWN delivered (attempt 1)
#   [   1.0s] after 2x DOWN  F2 = EXTRAS   ring   130    76    66    69   254
#   ✅ CONTROL PASSED: 2x DOWN moved TUTORIAL -> EXTRAS
#   [  13.3s] B delivered (attempt 1)
#   [  24.0s] BACK AT TITLE (glyph 1403)
#   [  25.8s] A delivered (attempt 1)
#   [  33.6s] MENU AGAIN  F3 = EXTRAS   ring   130    76    66    69   254
#
#   F1=TUTORIAL  F2=EXTRAS  F3=EXTRAS   => FOCUS PERSISTS
#
# The ring vector is menu_focus.py's geometry byte for byte: the peak moves from
# index 2 to index 4 and STAYS at 4 across the round trip.
#
################################################################################
# 🔴 RUN 1 IS DISCARDED, AND ITS FAILURE IS THE USEFUL PART.
#
# The first attempt read F1 = LOAD GAME and F2 = LOAD GAME -- the cursor had not
# moved -- and the control refused to report F3. The cause was NOT the reader:
# the two frames genuinely differ by 911 px, so they are different frames. It is
# that run 1 sent the DOWN presses through pad.py with NO delivery confirmation,
# while A and B were confirmed. The guest's own log settles it:
#
#   vk=5811 (dpad down) flags=0001 ... delivered ONCE for TWO presses
#   vk=5800 (A)         flags=0001 ... delivered once
#
# So a press that leaves the harness is not a press the guest received, and the
# corpus already knew that for A and B and had not applied it to the d-pad.
# Fixed: every press in this probe is now confirmed the same way, and the run
# above shows 2/2 DOWN delivered.
#
# ⚠️ REACH. One boot, one round trip, one direction. NOT tested:
#   * persistence across a full REBOOT -- this is within one boot;
#   * whether F1 = TUTORIAL here is an initial focus. IT IS NOT: run 1 had
#     already moved the cursor LOAD GAME -> TUTORIAL with its one delivered
#     press, and run 2 found it still on TUTORIAL. That is a second, incidental
#     confirmation of persistence -- across two separate probe processes -- but
#     it means this run says NOTHING about what the menu opens on.
#   * whether a longer absence, or a submenu round trip, behaves the same.
#     (Ⓑ from a submenu restoring the entered-from item is already 4/4.)