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/port/HANDOFF.md

@@ -6632,3 +6632,34 @@ now a clear reason no amount of re-testing through the file driver will ever
 produce one.** The next thing that could is patching repeat support into the
 file driver (proposed twice, not yet built) and re-running this exact
 capture. `-1.0` stays authored, not guessed, either way.
+
+## ✅ F1 — numbers, finally: 12 frames initial delay, 4 frames interval
+
+[`docs/re/f1-repeat-measured-via-driver-patch.md`](../re/f1-repeat-measured-via-driver-patch.md).
+Built the fix the previous entry named: patched Canary's file driver to
+emit `REPEAT` keystrokes using the SDL driver's own constants (400 ms
+delay / 100 ms interval, guest time — opt-in, off by default, every other
+scripted script unaffected), rebuilt, re-ran the identical held-⬇ capture.
+
+**The cursor moved continuously this time** — 19 distinct positions over
+one hold, cycling and wrapping through the whole 5-item list. At this run's
+achieved **29.87 fps** guest rate:
+
+* **initial delay: 12 frames** (~402 ms) from the ordinary press-triggered
+  step to the first repeat step;
+* **steady-state interval: 4 frames** (~133 ms) for 13 of 15 gaps, 3 frames
+  (~100 ms) for the other 2.
+
+**Use 12 and 4.** ⚠️ The interval is measurably slower than the raw 100 ms
+constant driving it (100 ms ÷ a ~33.5 ms frame is 2.99, not 4) — the game
+appears to consume repeat events at its own per-frame pace rather than
+instantly, and exactly why is not traced. The 4-frame figure is what
+actually matters: it's what the cursor visibly does, which is what a port
+needs to match.
+
+⚠️ **What this is not**: proof of what a *real controller* produces — it's
+what the game does when fed `REPEAT` events shaped like the SDL driver's,
+the closest thing to that oracle available in a container with no physical
+pad. One run only; the corpus's two-run minimum isn't met, and the
+3-vs-4-frame split in the interval is itself worth a second look. Good
+enough to stop authoring `-1.0` against, not yet good enough to call final.