fix(port): held_direction() polls the stick instead of reconstructing it

Reported by a human on a real controller: hold the left stick down, the
cursor moves one item and stops. The repeat never runs.

`held_direction()`'s own comment says "Polled at the DEVICE, never through
Input.is_action_pressed". It was not. The d-pad and keyboard branches polled;
the STICK branch read `_latched`, which is a reconstruction of the stick's
position from the event history.

That reconstruction is only as good as the last event seen. A stick held
still sends nothing, and one event reading below RELEASE -- a spring
settling, a deadzone-shaped value, a driver emitting a zero on focus change
-- clears it with no event afterwards to set it back. The port then believes
the stick is centred while the player is holding it, which is precisely the
symptom reported.

Now polls `Input.get_joy_axis()` against the game's own 0.61, which is what
the comment always meant. The latch stays as a fallback for INJECTED events,
so the script harness and verify-input keep testing something.

🔴 Every instrument here missed this because every instrument SUPPLIES the
input it measures: verify-input ticks repeat_due() directly, --script sends
InputEventAction which bypasses the input map, and the new --script=hold:
injects its own axis event. All three agreed with each other and none read a
device. Same shape as the 2026-09-01 report that opened gamepad.gd, one
level deeper, with the lesson already written at the top of that file.

So this adds the two things that would have caught it:

  --script=hold:down:2.0   hold one real axis deflection and log every move
  --input-probe            print what the devices report, on change

⚠️ The fix itself is NOT verified. It matches the symptom exactly and was
found by reading, but only a human holding a stick can confirm it, and the
probe exists so the answer is measured either way.

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

docs/port/held-direction-repeat.md

@@ -134,6 +134,55 @@ produced the press-triggered step — which is the origin the finding measures i
 12 frames from. Measured from `t = 0` the harness read 0.433 against 0.402 and
 the tolerance would have had to be widened to hide a units mismatch.
 
+## 🔴 It did not work on a real controller, and every instrument here said it did
+
+**Reported 2026-09-13, by a human holding a real stick: one step, then nothing.**
+
+`held_direction()`'s own comment said *"Polled at the DEVICE, never through
+`Input.is_action_pressed`"*. It was not. For the stick it read `_latched` — a
+reconstruction of the stick's position from the **event history** — and only the
+d-pad and keyboard branches actually polled anything.
+
+`_latched` changes only when an event arrives. A stick held perfectly still
+sends nothing, so the reconstruction is only as good as the last event seen, and
+any single event reading below `RELEASE` — a spring settling, a deadzone-shaped
+value, a driver emitting a zero on focus change — clears it with nothing
+afterwards to set it back. From then on the port believes the stick is centred
+while the player is holding it. That is exactly "it moves one item and stops".
+
+### Why nothing here caught it
+
+Every instrument in this repo **supplies the input it then measures**:
+
+| instrument | what it feeds |
+|---|---|
+| `verify-input`'s `repeat` rows | calls `repeat_due()` directly, after setting the latch through `accepts()` |
+| `--script=up,down,accept` | `InputEventAction` — bypasses the input map entirely |
+| `--script=hold:down:2.0` | injects one `InputEventJoypadMotion` |
+
+All three agreed with each other and none of them agreed with the controller,
+because none of them read a device. This is the same shape as the 2026-09-01
+report that opened `gamepad.gd`: *a synthetic-input test asserts the code after
+the input map, never the input map itself* — one level deeper, and it caught us
+again with the lesson already written down.
+
+### What changed
+
+`held_direction()` now polls `Input.get_joy_axis()` against the game's own 0.61,
+which is what its comment always meant. The latch survives as a **fallback for
+injected events**, because `Input.parse_input_event()` does move `get_joy_axis()`
+but the harness must keep working if that ever changes.
+
+And `--input-probe` prints what the devices report, on change:
+
+```
+probe: [0] Generic X-Box pad Y=+1.000 X=+0.000 dpad=--  latched=1  held_direction=1  (ENTER=0.61 RELEASE=0.40)
+```
+
+⚠️ **This fix is not verified.** It is a defect that matches the symptom exactly,
+found by reading, and the only instrument that can confirm it is a human holding
+a stick. The probe exists so that the answer is a measurement either way.
+
 ## What this does not claim
 
 * That the repeat feels right. It runs now, and **only a human can answer that**: