port: adopt the game's 61% stick threshold, and find my verify-screen numbers were llvmpipe-specific

Two things, and both are about a hidden parameter nobody was recording.

1. THE STICK THRESHOLD IS DECODED NOW, and it replaces an authored value.

The Decoder measured that the game digitises the left stick to four direction
bits at 61 % deflection, so it never sees a velocity. Gamepad.ENTER moves
0.5 -> 0.61. The 0.5 was never a chosen value: it was a FLOOR, because Godot's
`ui_*` action deadzone is 0.50 and the latch must not arm below it. Between 0.50
and 0.61 Godot reports a direction the real game does not, and at 0.5 this port
stepped there.

The mechanism also corroborates the human's latch fix rather than merely
agreeing with it: a control that digitises to bits cannot express a rate, so
"one step per deflection" is what the hardware layer CAN produce.

⚠️ The 0.11 hysteresis gap stays AUTHORED -- nothing says the game has
hysteresis at all. And a human chose 0.5, so this changes feel: revert the one
constant if 0.61 reads as needing too much push.

🔴 AND THE CONTROL CAUGHT MY FIRST ATTEMPT AT ASSERTING IT. I added the new
device-level row as subject "latch", and `verify-input --control` failed
immediately with "a check did not invert -- it is not testing what it claims to
test". It was right: removing the latch does not remove the THRESHOLD, the
unlatched path tests `>= Gamepad.ENTER` too, so 0.55 counts 0 either way and the
row could never invert. It is a NEGATIVE, and its positive control is the 0.70
row on the same shape. Reclassified.

That also exposed a smaller thing: ok()'s negative branch HARDCODED "positive
control is the stick row", so a second negative would have borrowed someone
else's green line. It now takes the control's name, defaulting to the original
text so the d-pad row is unchanged.

✅ I never consumed the pad bit table they have just corrected -- checked by grep
over port/, authored/ and tools/port/, not remembered.

2. MY verify-screen NUMBERS WERE llvmpipe-SPECIFIC, and the prediction failed.

Pre-registered: both renderers blend in encoded 8-bit space, so the diffs should
be identical or within 1 level on the GPU. They are not -- every mean rose 3-35 %:
title 0.4431 -> 0.5936, main_menu 3.9363 -> 4.1449, extras 6.7422 -> 6.9757,
title_jp 2.7715 -> 2.9448, main_menu_jp 0.7885 -> 1.0157, extras_jp 0.6592 ->
0.8906, build_12/15 0.0368 -> 0.0454.

But the MAXIMA are unchanged -- 41, 97, 113, 233, 17 identical, 26 -> 27 on one
row. That is a rounding population growing, not content moving: two rasterisers
round the last bit of a blend differently while the elements that genuinely
differ do not move.

Survives: the additive diagnosis, because it rests on an ORDERING and the
ordering holds (9 elements > 5 > 0); the pgloading_loop5 localisation; the
build_00/01 agreement; the derived allowance, same four failing rows.

Does not, and is now labelled: the histogram (53 % within 1 level, 16 844 over
40); every absolute mean; and the RMSE-vs-capture pair 3151.96 / 3769.61 -- that
ORDERING claim is not re-derived on the GPU and is not claimed until it is.

The rule this earns: a renderer comparison carries its RASTERISER as a hidden
parameter. Nothing here recorded which one produced a diff, and for months there
was only one so it never mattered. Same discipline TEMPORAL-VERIFICATION already
demands for capture rate, applied to what rasterises rather than what clocks.

Not settled: H1's repeat half; H6's +0x04 exposure; the four red verify-screen
rows; whether the port is still nearer the capture than the reference on the GPU.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX

tools/port/verify-input

@@ -60,7 +60,7 @@ var ran := 0
 ## removes it. A check whose subject cannot be removed is skipped there and
 ## counted, not silently dropped -- a control that quietly tests four of nine
 ## things reports the same green line as one that tests all nine.
-func ok(name: String, subject: String, cond: bool, detail: String = "") -> void:
+func ok(name: String, subject: String, cond: bool, detail: String = "", control_row: String = "the stick row (6 -> 1)") -> void:
 	if mode == "control" and subject == "godot":
 		print("  %-44s -- not controllable (Godot's own binding)" % name)
 		return
@@ -72,8 +72,12 @@ func ok(name: String, subject: String, cond: bool, detail: String = "") -> void:
 		# the same code path, reduces 6 stick events to 1. That row is the
 		# positive control for this one, and naming it is the honest move;
 		# inverting it would have been a green line that meant nothing.
-		print("  %-44s -- negative; positive control is the stick row (6 -> 1)"
-			% name)
+		# 🔴 The control row was HARDCODED here and a second negative arrived.
+		# A negative that names someone else's control is not controlled; it is
+		# borrowing a green line. `control_row` now defaults to the original
+		# text so that row is unchanged, and any new negative must say what
+		# actually backs it.
+		print("  %-44s -- negative; positive control is %s" % [name, control_row])
 		return
 	ran += 1
 	var want: bool = cond if mode != "control" else not cond
@@ -165,6 +169,26 @@ func _init() -> void:
 		nav([0.9, 0.45, 0.9, 0.45, 0.9]) == 1,
 		"%d step(s)" % nav([0.9, 0.45, 0.9, 0.45, 0.9]))
 
+	# ✅ THE GAME'''S OWN THRESHOLD, ASSERTED AT THE DEVICE LEVEL. The game
+	# digitises the stick to four direction bits at 61 % deflection, so a
+	# deflection between Godot'''s 0.50 action deadzone and that 0.61 is a
+	# direction the real game never sees. At the old ENTER = 0.5 this port
+	# stepped there. Negative first, then the positive control on the SAME run
+	# shape -- a negative alone would also pass if the latch were simply broken.
+	# 🔴 THIS ROW WAS "latch" AND THE CONTROL CAUGHT IT IMMEDIATELY. Removing
+	# the latch does not remove the THRESHOLD -- the unlatched path also tests
+	# `>= Gamepad.ENTER`, so 0.55 counts 0 either way and the row could never
+	# invert. The harness said so in one run: "a check did not invert -- it is
+	# not testing what it claims to test". It is a negative, and its positive
+	# control is the row below it: the same shape at 0.70 does step.
+	ok("0.55 is below the game 61 % threshold, must not step", "negative",
+		nav([0.55, 0.55, 0.55]) == 0,
+		"%d step(s)" % nav([0.55, 0.55, 0.55]),
+		"the 0.70 row on the same shape")
+	ok("...and its control: 0.70 on the same shape DOES step", "latch",
+		nav([0.70, 0.70, 0.70]) == 1,
+		"%d step(s)" % nav([0.70, 0.70, 0.70]))
+
 	# A button already IS an edge; latching it would swallow the second of two
 	# quick taps.
 	var pad := Gamepad.new()