re: F1 -- the "no auto-repeat" finding was measuring our own driver

Issue #1's premise (the human's play-test: a held direction repeats) directly
contradicted menu-navigation-semantics.md's 2026-08-30 "no auto-repeat"
row. Read the instrument before trusting either: nav_repeat_and_b.py drove
input through Canary's --hid=file driver, and that driver's GetKeystroke()
is explicitly, deliberately built to deliver exactly one event per held
press ("scripted input wants precisely one event per press, and repeat is
what makes menu steps overshoot" -- file_input_driver.h's own comment).
input-pad-read-path.md already established the game reads menu input via
this same Keystroke API. A driver engineered to prevent repeat cannot be
evidence the game lacks it -- the counter's control (a tap gives 1 spike)
proved the counter works, not that the driver could show more than one.

Not a clean reversal, and said so: the same driver's GetState() holds a
button continuously with no edge suppression, and pad.py's own docstring --
written by an earlier session driving this exact tool -- warns that a longer
dpad hold "auto-repeats and overshoots," describing an observed effect
through this same driver. The two pieces of evidence disagree and this page
does not resolve which wins.

Also read from Canary's source: the SDL input driver (what a real controller
goes through) auto-repeats keystrokes at 400 ms initial delay then 100 ms
interval, guest time (HID_SDL_REPEAT_DELAY/RATE, upstream Xenia, not a
project change) -- a concrete, testable prediction for what the real number
could be if the menu treats repeat-flagged keystrokes as nav steps, matching
the human's "medium pace" description. Not yet measured.

Refutation attempt this iteration, recorded per adversarial duty: targeted
the 2026-08-30 "no auto-repeat, ✅ measured" claim. Survives only partially --
demoted to unsettled, not flipped to a confident opposite. New REFUTED.md
section (Menu navigation and input) and the row in
menu-navigation-semantics.md both corrected in place, old text kept per
convention.

What would close it: trace C_PAD_RINGBUF's producer (keystroke ring vs
polled state) statically, or add an opt-in repeat mode to the file driver
and read cursor position off the draw log per frame. Neither run this
iteration -- this is the static half, and reversing a standing claim is
enough for one unit without stacking a build-and-boot run on top of it
unverified.

docs/re/REFUTED.md

@@ -1071,3 +1071,26 @@ separate the four frames from anything.
 the right place to look, and it answered — the frames are drawn additive, exactly
 as their own two-background composite solve had ranked them. A wrong reason
 attached to a right direction; only the reason is refuted here.
+
+## Menu navigation and input (2026-09-12)
+
+* 🟡 "a held direction moves the cursor exactly once — no auto-repeat"
+  (`data/nav-autorepeat-and-settled-b.txt`, 2026-08-30) — **its own instrument
+  disagrees with itself.** `--hid=file`'s `GetKeystroke()` is written to
+  deliver exactly one event per held press, by explicit design ("scripted
+  input wants precisely one event per press, and repeat is what makes menu
+  steps overshoot" — `file_input_driver.h`), and `input-pad-read-path.md`
+  already found the game reads menu input through this same Keystroke API.
+  A driver built to prevent repeat cannot be evidence the game doesn't have
+  it. The counter's own control (a single tap gives exactly 1 spike) proves
+  the *counter* works; it says nothing about the *driver* it was counting
+  through. **Complication, not a clean reversal:** the same driver's
+  `GetState()` holds a button continuously with no edge-suppression, and
+  `pad.py`'s own docstring — written by an earlier session driving this
+  exact tool — warns that a longer `dpad` hold "auto-repeats and
+  overshoots," which is a claim of an observed effect through this driver,
+  not a hypothetical. The two do not agree. **To settle:** trace
+  `C_PAD_RINGBUF`'s producer (keystroke ring vs. polled state) — no
+  emulator needed — or re-run with a repeat-capable file driver and read
+  cursor position off the draw log per frame, not a coarse screen-diff.
+  [`f1-no-repeat-was-the-harness.md`](f1-no-repeat-was-the-harness.md) ⟨harness⟩