re: F1 measured -- held DOWN moves the cursor once and no more, via the file driver

Fifth boot attempt this session, first clean one, using the harness debugged
last iteration (env-safe input, wide capture window, signed-in profile,
blanked X root). Reached the menu, held DOWN 2.5s wall-clock, armed the F10
draw capture, released, killed -- zero crashes.

Achieved vs requested: 433 of 600 requested frames, spanning 14.43s of GUEST
time against ~4.5s wall-clock for the hold+tail window -- this run went at
~3.2x real time (a cheap static menu, nothing pacing it to a display
refresh). The 2.5s wall-clock hold covers roughly 8s of that guest time.

Method: track one quad shape's position per frame via read_draws.py, not a
screen diff -- the approach f1-menu-repeat-harness-built-not-answered.md
already named as correct. Exactly one shape-group moves at all: one jump of
~0.21-0.225 NDC units (matching the known one-menu-item pitch), complete
within 4 frames / 133ms guest time of arming, then flat (a ~0.0125 pulse
wobble only) for the remaining 427 frames / 14.3s of guest time. Broadening
the match threshold finds no other moving element.

This is a STRONGER negative than the 2026-08-30 result it agrees with (that
one sampled a screen diff at ~4-5fps for 2.0s; this reads every quad every
frame for ~8s of guest-time held) -- it survives, rather than confirms, last
iteration's "coarse sampling hid a fast repeat" alternative, which does not
survive a per-frame instrument over a much longer window. Refutation
attempt against my own prior lean, recorded: it does not survive.

Reconciled, not left in conflict: the human's play-test and pad.py's
"auto-repeats" warning almost certainly went through a REAL controller
(Canary's SDL driver), which auto-repeats keystrokes at a documented
upstream 400ms/100ms (guest time) via the REPEAT keystroke flag. The file
driver deliberately never emits that flag, by design -- so it cannot show
repeat regardless of how carefully or how long it's held, which is exactly
the negative measured here. Still no F1 number; now a specific, well-
evidenced reason the file driver alone will never produce one, and a named
next step (add opt-in REPEAT-flag support to the file driver, matching the
SDL driver's constants, then re-run this exact capture) -- not attempted
this iteration, a second unit on an already-complete one.

Reference data: docs/re/data/f1-cursor-quad-y-per-frame.tsv -- the derived
per-frame Y position and guest tick, not the raw draw log itself (a capture
artifact, kept uncommitted per the corpus's game-content rule).

docs/re/REFUTED.md

@@ -1094,6 +1094,20 @@ attached to a right direction; only the reason is refuted here.
   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⟩
+  🔴 **Half of "to settle" done 2026-09-12, and it points back the other
+  way.** Re-ran with the *existing* file driver, tracking one quad shape's
+  position per frame (not a screen diff): one real move, caught cleanly at
+  133 ms guest resolution, then **nothing for the remaining ~8 s of guest
+  time the button was held** — a stronger negative than the original, not a
+  reversal of it. This also refutes my own leading alternative from the
+  `C_PAD_RINGBUF` trace (that a coarse screen-diff was hiding a fast
+  polled-state repeat): a per-frame instrument over a much longer held
+  window still finds nothing. Reading now favours Keystroke-`REPEAT`-driven
+  menu navigation after all — which the file driver cannot produce by
+  design, regardless of how carefully it's held — over the polled-state theory.
+  Still 🟡, not ❌: only the file-driver path is tested; the SDL-driver path
+  (what a real controller and the human's play-test went through) is not.
+  [`f1-held-down-measured-no-repeat-via-file-driver.md`](f1-held-down-measured-no-repeat-via-file-driver.md) ⟨capture⟩
 * "F10-arming a UI draw capture is safe on any settled screen" — **implicit
   in every prior use of it, and false in a fresh container.** A `run-canary`
   launch with no signed-in profile (every container right after a restart —