re(flight): the rate probe measures a MOVING speed -- pitching bleeds it hard

Measured pitch with the rows properly pinned, against this craft's own disc caps
(AV_PitchPlus_Min 150, AV_PitchPlus_Max 70):

    min speed (LT)  1391.0 deg / 8.00 s, clock x1.326 -> 131.1 deg/game-s  vs 150
    max speed (RT)   989.0 deg / 8.05 s, clock x1.318 ->  93.2 deg/game-s  vs 70

A rate 33% ABOVE a cap is not a finding, it is a broken instrument. The HUD speed
is in the same bracketing screenshots that give the clock, so read it:

    slow phase   102 ->  18
    fast phase  1193 -> 589

The speed is NOT constant during the dwell -- pitching halves it in 8 seconds.
The cap is speed-dependent, so as the craft slowed its cap rose, and an 8-second
average necessarily lands between the max-speed cap and a mid-speed one. The 133%
is entirely the instrument.

This also weakens the roll result committed earlier: same method, so 120.9 vs
AV_Roll_Max 125 is CONSISTENT but is not a tight test -- the true cap could be
lower and still produce that average. Said plainly in the doc rather than left
standing as a clean confirmation. Min-speed figures are less affected; there is
little speed left to lose.

Proper fix, not yet done: dwell ~1-2 s so speed barely moves, or sample HUD speed
continuously and fit rate against INSTANTANEOUS speed -- which yields the whole
rate-vs-speed curve instead of two points.

Separately this is a flight-model finding: TURNING COSTS SPEED, steeply, with the
throttle still at maximum. A reimplementation treating the throttle as a speed the
craft simply holds will be wrong during manoeuvres.

docs/re/flight-speed-law.md

@@ -504,3 +504,44 @@ should model as such.
 🟡 Not covered: the **d-pad** (the tactical map) and the **face buttons** (fire /
 weapon select). Neither is a plausible flight axis, but neither was measured here.
 Data: [`captures/axis-probe-rows-pinned.csv`](captures/axis-probe-rows-pinned.csv).
+
+
+## ⚠️ Angular-rate probes measure a MOVING speed — the dwell bleeds it
+
+Measuring pitch with the rows properly pinned gave, for
+`UN_f001_TCAF_DeltaSaber_T_Player` (whose own disc values are
+`AV_PitchPlus_Min` **150°**, `AV_PitchPlus_Max` **70°**):
+
+| phase | swept | clock | per game-s | cap |
+|---|---|---|---|---|
+| min speed (`LT`) | 1 391.0° / 8.00 s | ×1.326 | **131.1** | 150 |
+| max speed (`RT`) | 989.0° / 8.05 s | ×1.318 | **93.2** | 70 — **133 % of cap** |
+
+A rate 33 % *above* a cap is not a finding, it is a broken instrument, so read the
+HUD speed off the same bracketing screenshots that gave the clock:
+
+```
+slow phase   102  ->   18
+fast phase  1193  ->  589
+```
+
+**The speed is not constant during the dwell — pitching bleeds it hard**, halving it
+in 8 seconds. The rate cap is itself speed-dependent, so as the craft slowed its cap
+*rose*, and the 8-second average necessarily lands between the max-speed cap and a
+mid-speed one. The 133 % is fully explained by the instrument.
+
+**This weakens the roll numbers above as well.** They were taken the same way, so
+`120.9` vs `AV_Roll_Max` `125` is *consistent* but is **not a tight test** — the true
+max-speed roll cap could be lower and still produce that average. The min-speed
+figures are less affected (there is little speed left to lose).
+
+**How to measure it properly** (not yet done): keep the dwell to ~1–2 s so the speed
+barely moves, or sample the HUD speed continuously and fit rate against
+*instantaneous* speed rather than assuming the endpoint. The second is strictly
+better and gives the whole rate-vs-speed curve rather than two points.
+
+**And a flight-model finding in its own right:** *turning costs speed*, steeply —
+1 193 → 589 under 8 s of full pitch, with the throttle still held at maximum. A
+reimplementation that treats the throttle as setting a speed the craft simply holds
+will be wrong during manoeuvres. Data:
+[`captures/pitch-rate-speed-bleed.csv`](captures/pitch-rate-speed-bleed.csv).