re: F1 -- traced C_PAD_RINGBUF; the queue naming inference was wrong

Continuing the F1 investigation rather than starting a fresh one. Last
iteration left two competing hypotheses open (Keystroke-queue-driven vs
polled-state-driven repeat) and flagged C_PAD_RINGBUF's producer as the
cheapest thing to trace next -- named but not traced.

Traced it this time: C_PAD_DECODER's own constructor (sub_8220B610)
allocates C_PAD_RINGBUF (52-byte control struct, 1024-byte backing buffer,
confirmed against its own Shift-JIS trace strings -- "C_PAD_RINGBUF
initialization" and its allocation-error message). Its update function
(sub_8220B8C0) takes the input-manager singleton as a parameter and reads
the ring at offsets 12, 36, 40, 44 and 48 -- not just the one button word.

Offsets 36-48 are four consecutive fields read together through the same
int-to-double conversion an analog axis would use. XamInputGetKeystrokeEx
has no field for a stick position, so a structure carrying four axis-shaped
fields cannot be a keystroke queue -- it reads as a periodically-refreshed
polled-state snapshot. My own prior reading of the "ring buffer" name as
implying a queue was the wrong inference; refuted by tracing it, recorded
either way per adversarial duty.

This shifts the balance toward the second, previously-uncertain hypothesis:
the file driver's GetState() was always capable of showing real repeat (no
modification needed), and nav_repeat_and_b.py's null result is more likely
a sampling artifact of its ~4-5 fps screen-diff detector than a structural
driver limit. Revises "what would close it" accordingly -- re-run the
existing draw-log position-tracking instrument, gated on the menu properly,
before reaching for a driver change.

Not found: the actual producer that writes into C_PAD_RINGBUF each frame --
narrowed to "reachable from the input-manager singleton fetch in
sub_821A9DC8," not traced to completion. Still no number for issue #1;
this narrows the path to one, further than last iteration but not there.

docs/port/HANDOFF.md

@@ -6583,3 +6583,13 @@ and it competes with a second reading of the evidence that isn't resolved
 either (see the page for both). **Keep authoring against `-1.0` until a
 capture backs one of these**, same as before — this narrows why the number
 is missing, it doesn't supply one.
+
+**2026-09-12 update, same page:** traced `C_PAD_RINGBUF` (the structure the
+game's own pad decoder reads) and it carries four axis-shaped fields
+alongside its button word — a shape only the **polled** controller state has
+(analog sticks have no keystroke equivalent), not a keystroke queue as the
+name alone had suggested. That favours the "the driver was always capable,
+the coarse screen-diff detector undercounted" reading over the
+Keystroke/400-100ms one, though neither is confirmed yet and the actual
+producer still isn't found. Still no number — still don't take one from
+here.