re: F1 answered -- 12 frames initial delay, 4 frames interval, by patching in the repeat the driver lacked

Direct follow-through on this session's own named next step. The prior
result (f1-held-down-measured-no-repeat-via-file-driver.md) concluded the
file driver cannot show menu repeat because its GetKeystroke() never emits
a REPEAT-flagged event, and that the menu's repeat is very likely driven by
that flag rather than raw polled state. Testable, so tested: patched
/canary/src/xenia/hid/file/file_input_driver.h to add opt-in repeat behind
a new --pad_file_repeat cvar (off by default, every other scripted script
unaffected), using the SDL driver's own constants verbatim
(HID_SDL_REPEAT_DELAY/_RATE = 400/100, guest-time ms via
Clock::QueryGuestUptimeMillis) rather than re-deriving them. Incremental
rebuild, ~1 minute (only xenia_main.cc needed recompiling).

Control: the driver's own log confirms repeated keystroke events fire as
designed, zero crashes.

Result: re-ran the identical held-DOWN capture. The cursor that moved once
and stopped in the null result now cycles continuously through the whole
5-item menu, wrapping, for as long as the button is held -- the null result
was real for that driver path, and giving the driver the one thing it
lacked reverses it completely.

Measured at this run's achieved 29.87 fps guest rate: 12 frames (~402ms)
initial delay from the press-triggered step to the first repeat step; 4
frames (~133ms) steady-state interval for 13 of 15 gaps, 3 frames (~100ms)
for the other 2 -- slower than the raw 100ms constant driving it, which
this page flags but does not trace further (most likely the game batches
drained keystrokes per its own frame tick rather than reacting to each one
instantly). The 4-frame figure is what matters for the port: it's what the
cursor visibly does.

Honestly scoped: this measures what the game does when FED repeat events
shaped like the SDL driver's, not a capture through an actual physical
controller (none exists in this container) -- classified measured, not
decoded, for exactly that reason. One run only; the corpus's two-run
minimum isn't met, flagged rather than overclaimed.

f1_hold_capture.py gains an optional `repeat` argument. The Canary source
patch itself lives in /canary, outside this repo (Canary source, not
sylpheed-formats) -- fully described inline in the finding doc so it can be
reapplied if that tree doesn't persist across a container reset.

Reference data: docs/re/data/f1-repeat-cursor-transitions.tsv -- every
transition's frame, guest tick and Y position, not the raw draw log.

docs/re/REFUTED.md

@@ -1108,6 +1108,13 @@ attached to a right direction; only the reason is refuted here.
   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⟩
+  ✅ **The other half done, same day — the Keystroke-`REPEAT` reading is
+  confirmed, not just favoured.** Patched the file driver to emit `REPEAT`
+  at the SDL driver's own constants (opt-in, off by default), rebuilt,
+  re-ran the identical capture: the cursor that moved once and stopped now
+  cycles continuously through the whole menu for as long as the button is
+  held. Measured: 12 frames initial delay, 4 frames steady interval, at
+  29.87 fps guest. [`f1-repeat-measured-via-driver-patch.md`](f1-repeat-measured-via-driver-patch.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 —