re(flight): the ramp test is inconclusive, and names the tool the residual needs

To separate "a 1 s burst never reaches the steady rate" from "a per-axis
multiplier", measure inside ONE hold: successive 0.25 s windows of a single 3 s
press, holding speed, attitude and starting conditions constant by construction.

    rep0 rate   16   59  325  209  130  322  238  110  310  151  183
    rep1 rate   52  181  231  246  236  169  368  195  181  255  182

Not usable. At 0.25 s the windows do not contain enough guest updates to average,
so rate and speed both swing 3x window to window -- the same aliasing that once
manufactured a rate-vs-speed curve, reappearing at finer resolution. The first
window is lowest in BOTH repeats, which is what a ramp would look like, but the
sequence never plateaus, so the signal cannot be separated from the sampling. No
claim either way.

Widening the window does not rescue it: 0.5 s averages well enough, but a hold
long enough to contain several 0.5 s windows bleeds speed -- and speed is the
variable under test. The two effects are entangled at this observation rate.

So the residual needs a different INSTRUMENT, not another script. Live-RAM polling
samples an unsynchronised snapshot; the question wants the craft's angular
velocity as the guest computes it, once per frame. That is a Canary-side hook --
the same shape as the existing F10 ship-capture patch -- and the rebuild toolchain
already makes it cheap. Recorded as the recommendation rather than attempted as a
seventh variation of the same measurement.

docs/re/flight-speed-law.md

@@ -702,3 +702,37 @@ so the row pin came back **WEAK** (margin 0.109). That refusal is correct for pi
 and yaw — but **roll is immune to the up/right labelling**, which is exactly what the
 guard's own message says, so `ALLOW_WEAK_PIN=1` is the documented and legitimate
 override there. It is worth having a guard that states its own exception.
+
+
+## The ramp test is inconclusive — and says what the next tool must be 🟡
+
+To separate "a 1 s burst never reaches the steady rate" from "a per-axis multiplier",
+the cheapest test measures *inside* one hold: successive 0.25 s windows of a single
+3 s press, so speed, attitude and starting conditions are held constant by
+construction. Two repeats, roll, at cruise:
+
+```
+rep0 rate   16   59  325  209  130  322  238  110  310  151  183
+     speed 390  234  574  341  223  526  387  191  511  247  312
+rep1 rate   52  181  231  246  236  169  368  195  181  255  182
+     speed 447  372  378  418  385  233  590  307  312  419  306
+```
+
+**Not usable.** At 0.25 s the windows do not contain enough guest updates to average,
+so both channels swing by 3× window to window — the same aliasing that once
+manufactured a rate-vs-speed curve, reappearing at finer resolution. The first window
+is the lowest in *both* repeats, which is what a ramp would look like, but the
+sequence never plateaus, so the signal cannot be separated from the sampling.
+
+**Widening the window does not rescue it**: 0.5 s windows average well enough (that is
+what the earlier sweep used), but a hold long enough to contain several of them bleeds
+speed, and speed is the very variable under test. The two effects are entangled at
+this observation rate.
+
+**So this residual needs a different instrument, not another script.** Live-RAM polling
+samples an unsynchronised snapshot; what the question wants is the craft's angular
+velocity *as the guest computes it, once per frame*. That is a Canary-side hook —
+the same shape as the existing F10 ship-capture patch — and the rebuild toolchain
+already makes it cheap. Recorded as the recommendation rather than attempted as a
+seventh variation of the same measurement.
+Data: [`captures/roll-ramp-inconclusive.csv`](captures/roll-ramp-inconclusive.csv).