re(flight): withdraw the roll result — the probe was measuring pitch as much as roll

Re-running roll with 5 s settles and in-run clock brackets:

  this run's clock: TIME 00:34.93 -> 00:45.97 = 11.04 s game in 7.98 s wall = 1.383
  min speed: 90.6 deg/wall-s /1.383 -> 65.5 deg/game-s  (AV_Roll_Min 200)
  max speed: 59.1            /1.383 -> 42.7             (AV_Roll_Max 125)

The corrected numbers are within a few per cent of the PITCH run's 67.8 and 40.9 —
two different stick axes cannot produce the same rates, so the probe is not
separating them. Cause: watching a non-forward matrix row sees any rotation that
moves that row, and pitch moves it as much as roll. The correct measure is rotation
ABOUT the forward axis (project the row onto the plane perpendicular to forward and
track that angle).

So "roll shows no speed dependence, unlike pitch" is withdrawn: it rested on 2 s
settles and a row that mixes axes, and the two runs disagree with each other
(144/150 then, 90.6/59.1 now). AV_Roll_{Min,Max} are not confirmed and the axis
question is open.

The clock ratio is now measured three times in three flights: 1.260, 1.311, 1.383 —
a property of the moment, not the machine, so every rate probe must bracket its own
phases.

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

docs/re/flight-speed-law.md

@@ -384,3 +384,39 @@ image still parses, and the scans quietly report `0 moving triples` / "player en
 not found" — which reads like a tooling bug. `pgrep -x xenia_canary` does **not**
 help: zombies match it. `speed_law.require_live_emulator()` now checks the process
 *state letter* and refuses to measure a corpse, naming the stale image in its error.
+
+---
+
+# ⚠️ The roll result is WITHDRAWN — the probe was not isolating roll
+
+Re-running the roll phases with 5 s settles and in-run clock brackets
+([`tools/re-capture/roll_gametime.py`](../../tools/re-capture/roll_gametime.py)):
+
+```
+this run's clock:  TIME 00:34.93 -> 00:45.97  =  11.04 s game in 7.98 s wall  =  1.383
+minimum speed:  90.6 °/wall-s  ÷ 1.383 ->  65.5 °/game-s   (AV_Roll_Min 200)
+maximum speed:  59.1 °/wall-s  ÷ 1.383 ->  42.7 °/game-s   (AV_Roll_Max 125)
+```
+
+Two things are wrong with reading this as "roll".
+
+* The corrected numbers — **65.5 and 42.7** — are within a few per cent of the
+  **pitch** run's **67.8 and 40.9**. Two different stick axes producing the same
+  rates is the signature of a measurement that is not separating them.
+* Watching a non-forward matrix row sees **any** rotation that moves that row, and
+  pitch moves it as much as roll does. The forward row was the wrong thing to avoid;
+  what is needed is the rotation **about** the forward axis — project the row onto
+  the plane perpendicular to forward and track the angle of that projection.
+
+So the earlier conclusion — *"roll shows no speed dependence, unlike pitch"* — is
+**withdrawn**. It rested on 2 s settles (which this session has twice shown to
+produce wrong answers) and on a row that mixes the axes. The two runs do not even
+agree with each other (144/150 then, 90.6/59.1 now), which is itself the tell.
+
+What survives: `AV_Roll_{Min,Max}` are **not** confirmed, and the axis question —
+does roll follow the same speed rule as pitch? — is **open**, with the correct
+measurement specified above.
+
+**The clock ratio has now been measured three times in three flights: 1.260, 1.311,
+1.383.** It is not a property of the machine but of the moment, so any rate probe
+must bracket its own phases.