re(flight): the linear discrepancy is a world-unit vs displayed-speed difference

Screenshotting the HUD speed readout at each throttle step, beside the
position-derived measurement of the same moment:

  RT 0.00   HUD 350 (= CruisingVelocity)   position ~447   ratio 1.28
  RT 0.25   HUD 507                        position ~652   ratio 1.29
  RT 0.75   HUD 963                        position ~1141  ratio 1.19

So (a) the HUD speaks the definition's units — exactly CruisingVelocity at neutral,
963 at three-quarters against the 987 the interpolation predicts — confirming the
throttle law in the game's own numbers without any position sampling; and (b) world
displacement runs ~1.2x the displayed speed. Since settled angular rates need no such
factor, this is a unit difference between the position triple and the velocity
fields, not a clock effect: a reimplementation moving entities at MaximumVelocity in
world coordinates will be ~20% slow.

Also fixes speed_law.find_player: a mission holds more than one *_Player object and
at least one never moves, so the finder now samples each candidate twice and keeps
the one that displaces. Locking onto the static one is what produced a run of exact
zeros while the game was visibly flying.

🟡 The ratio is 1.19-1.29 rather than a clean constant and every sample was taken in
a firefight; pinning it wants a quiet map.

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

@@ -261,3 +261,45 @@ not discriminate lerp-versus-switch, because at half throttle the craft only rea
 this probe's noise.
 
 Raw samples: [`captures/turn-law-settled.csv`](captures/turn-law-settled.csv).
+
+---
+
+# The linear discrepancy is real, and it is between WORLD units and DISPLAYED speed
+
+Last section removed the "time base" explanation by showing settled *angular* rates
+match the definition exactly. That leaves the linear side, and the HUD settles it:
+screenshotting the speed readout at each throttle step, next to the position-derived
+measurement of the same moment
+([`captures/throttle-curve-hud.csv`](captures/throttle-curve-hud.csv)):
+
+| `RT` | HUD readout | position-derived | ratio |
+|---|---|---|---|
+| 0.00 | **350** (= `CruisingVelocity`) | ~447 | 1.28 |
+| 0.25 | **507** | ~652 | 1.29 |
+| 0.75 | **963** | ~1 141 | 1.19 |
+
+Two things follow.
+
+* **The HUD speaks the definition's language.** It reads exactly `CruisingVelocity`
+  at neutral and climbs toward `MaximumVelocity` as the trigger is pressed — 963 at
+  three-quarters, against the 987 the interpolation predicts. So the throttle law
+  stated above is confirmed in the game's *own* units, independent of any position
+  sampling.
+* **World displacement runs ~1.2× the displayed speed.** Since the angular rates
+  need no such factor, this is not a clock effect: it is a **unit difference between
+  the position triple and the velocity fields**. A reimplementation that places
+  entities in world coordinates and moves them at `MaximumVelocity` will be ~20 %
+  slow.
+
+🟡 The ratio is 1.19–1.29 across the three points rather than a clean constant, and
+every sample was taken in a firefight where the craft is also being pushed. Pinning
+it exactly wants a quiet map or a scripted straight run; the *existence and rough
+size* of the factor is what these measurements support.
+
+**A methodological note worth keeping.** This line of work went: hold a trigger →
+"three target speeds" → analogue interpolation → an unexplained 1.2× → "time base"
+→ withdrawn → a *unit* difference confined to the linear side. Every step came from
+one of two moves: **let a held input vary** (the trigger's analogue range), or
+**bring in an independent oracle** (the HUD, the definitions, a longer settle). The
+wrong turn — the time base — came from explaining a number instead of first
+measuring the same quantity a second, cleaner way.