feat(port): adopt the measured held-direction repeat rate (F1)

REPEAT_DELAY = 0.402, REPEAT_INTERVAL = 0.134, from
docs/re/f1-repeat-measured-via-driver-patch.md -- 12 and 4 frames at the
run's achieved 29.87 fps guest rate, converted to seconds because this port
does not run at the guest's rate and it is the cadence that was measured.

The mechanism has been here since 2026-09-02 and inert on purpose. The
instruction it was waiting on is now vindicated in the most awkward way: the
draft it refused to ship had 0.40 / 0.20, so the guessed delay was nearly
right and the guessed interval was off by 50 %. The half that was wrong
would have been protected by the half that was right.

The delay and the interval are NOT equally well evidenced, and the code says
so at the constants. No physical controller exists in the Decoder's
container, so the measurement fed Canary's file driver the SDL driver's own
400/100 ms constants: the 402 ms that came back is the constant that went
in, and confirms the instrument. The 133 ms interval against a fed-in 100 ms
is the new fact -- the game paces repeats to its own frame consumption. One
run; the two-run minimum is not met and the finding says so itself.

Also: the prediction that this would turn verify-input's "a held stick is
ONE step, not six" red was wrong. It stayed green, because steps() never
advances a clock and so had never called repeat_due() at all -- the rate was
about to ship into a harness with no coverage of the feature, with a green
line that would have been read as coverage.

So verify-input gains a `repeat` subject: nothing before the delay, the
first repeat on the delay, the steady interval, cadence independent of frame
rate (the code claims this in a comment, so it is now asserted), and a
direction change restarting the delay. Each asserts THESE numbers, not the
shape -- a shape-only check would have passed on 0.40 / 0.20. The control
removes the premise, a held direction, and every controllable row inverts.

The first-repeat row measures from the arming tick, not from t=0: that tick
is the frame the press is handled, which is the origin the finding measures
its 12 frames from. Measured from zero it read 0.433 vs 0.402 and the
tolerance would have had to be widened to hide a units mismatch.

Closes #2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

port/scripts/gamepad.gd

@@ -100,17 +100,43 @@ const RELEASE := 0.4
 ## too."* So the FACT covers both input devices, which is why `held_direction()`
 ## polls the pad and the keyboard and not just the stick.
 ##
-## 🔴 **THE RATE IS DELIBERATELY UNSET, AND THE REPEAT DOES NOT RUN UNTIL IT IS
-## MEASURED.** The instruction is explicit: *"Take the RATE from the Decoder — do
-## NOT ship a placeholder interval. An invented rate here is indistinguishable
-## from a measured one later, and this is the exact field where that already cost
-## us."*
+## ✅ **THE RATE IS NOW MEASURED, 2026-09-12, and adopted here.**
+## `docs/re/f1-repeat-measured-via-driver-patch.md`, with the per-transition
+## reference data in `docs/re/data/f1-repeat-cursor-transitions.tsv`.
 ##
-## An earlier draft of this file had 0.40 / 0.20 with a paragraph explaining that
-## they were authored. **That is precisely the failure mode named above** — the
-## explanation would have been merged, the numbers would have felt roughly right,
-## and nothing afterwards could distinguish them from a measurement. They are
-## removed rather than commented out.
+## ~~THE RATE IS DELIBERATELY UNSET, AND THE REPEAT DOES NOT RUN UNTIL IT IS
+## MEASURED.~~ It ran unset for eleven days and that was the right state; the
+## paragraph is struck through rather than deleted because the reason it gave is
+## the reason these two numbers can be trusted now. An earlier draft had
+## **0.40 / 0.20** with a note saying they were authored — and 0.40 would have
+## looked vindicated today while 0.20 was off by 50 %. That is exactly why an
+## explained guess is worse than none: half of it would have been right.
+##
+## ## Where the two numbers come from, and how far they reach
+##
+## Measured in Canary at an achieved **29.87 fps** guest rate: **12 frames**
+## from the press-triggered step to the first repeat, then **4 frames** per step
+## (13 of 15 gaps; 3 frames for the other 2). Converted to seconds here, not
+## frames, because this port does not run at the guest's rate and it is the
+## *cadence* that was measured — 12 / 29.87 = 0.402, 4 / 29.87 = 0.134.
+##
+## ⚠️ **THE DELAY IS WEAKER EVIDENCE THAN THE INTERVAL, and they should not be
+## trusted equally.** No physical controller exists in that container, so the
+## measurement was taken by patching Canary's `--hid=file` driver to emit
+## Keystroke `REPEAT` at the SDL driver's own 400 ms / 100 ms constants. The
+## 402 ms that came back is, to within the frame quantum, **the constant that
+## was fed in** — it confirms the instrument, not the game. The 133 ms interval
+## is the genuinely new fact: the driver was fed 100 ms and the cursor moved
+## every 133, so the game paces repeats to its own frame consumption rather
+## than to the event stream.
+##
+## So: the interval is what the game does. The delay is what Xenia's SDL driver
+## does, and the game was not observed to disagree with it. If a capture through
+## a real controller ever contradicts 0.402, that is the number to move.
+##
+## 📌 One run. The corpus's own two-run minimum is **not met** — the source page
+## says so itself, and this comment repeats it rather than letting the constant
+## look firmer at the call site than it does at the finding.
 ##
 ## 📌 **A constant interval is the right SHAPE, and that part IS measured.** The
 ## game digitises the left stick to four direction bits at 61 % deflection
@@ -118,20 +144,27 @@ const RELEASE := 0.4
 ## drives cannot be faster-the-harder-you-push. That excludes the one competing
 ## model, so only the two constants are open, and one measurement closes both.
 ##
-## ⚠️ **TO ADOPT, TWO THINGS CHANGE, NOT ONE.** Set both constants to the
-## measured seconds — and update `tools/port/verify-input`, whose row *"a held
-## stick is ONE step, not six"* currently asserts **the absence of this
-## feature**. It passes today because the repeat is inert; the moment a rate is
-## adopted a held stick SHOULD produce further steps, and that green row would
-## go red for the right reason and be read as a regression.
+## ⚠️ ~~**TO ADOPT, TWO THINGS CHANGE, NOT ONE.** … that green row would go red
+## for the right reason and be read as a regression.~~
 ##
-## 📌 That row is not wrong. A check written against today's behaviour becomes an
-## assertion that the behaviour never changes, and this one has the additional
-## trap of looking like a bug-fix regression test — it was written for the
-## jitter defect, and the repeat is not that defect returning.
-## `pad-repeat` in `BLOCKED.md` carries the request.
-const REPEAT_DELAY := -1.0
-const REPEAT_INTERVAL := -1.0
+## 🔴 **RUN ON ADOPTION DAY: THE ROW STAYED GREEN, AND THAT IS WORSE.**
+## `verify-input`'s `steps()` never advances a clock, so it had never called
+## `repeat_due()` at all — the row it warned about tests the *latch*, which the
+## repeat does not touch. The prediction was reasoned rather than run, and what
+## it hid is the real problem: the rate was about to ship into a harness with
+## **no coverage of this feature whatsoever**, and the green line would have
+## been read as coverage.
+##
+## The fix was not to change that row. It was to add a `repeat` subject that
+## holds a direction through the same latch and ticks `repeat_due()`, asserting
+## **these two numbers** rather than "it repeats eventually" — a shape-only
+## check would have passed on the 0.40 / 0.20 guess this file refused to ship.
+##
+## 📌 The original point survives intact and is worth keeping: a check written
+## against today's behaviour becomes an assertion that the behaviour never
+## changes. It was simply aimed at the wrong row.
+const REPEAT_DELAY := 0.402
+const REPEAT_INTERVAL := 0.134
 
 
 ## Whether a measured repeat rate has been adopted. Until it has, the port keeps