re(flight): both axes at settled speeds -- shape confirmed, absolute scale is not

Burst design repeated with the HUD clock bracketed (01:01.86 -> 02:10.61, ~x1.26)
and roll measured in the same flight.

    pitch   87.0 @ 85    82.8 @ 308    47.0 @ 1077   min:max 1.85
    roll   125.0 @ 76   119.0 @ 291    82.6 @ 1023   min:max 1.51

SHAPE CONFIRMED on both axes: the rate interpolates between _Min (at minimum
speed) and _Max (at maximum speed), matching to 1.6% for pitch (vs PitchMinus
75/40 = 1.88) and 5.6% for roll (vs 200/125 = 1.60). Both ratios are
clock-independent so they stand regardless of the conversion, and pitch's
re-confirms ly+ = pitch-MINUS (reproducing 1.82 from the previous run).

ABSOLUTE SCALE DOES NOT MATCH, and not in the same direction:

    pitch  measured/predicted = 1.15, 1.21, 1.07   consistently OVER
    roll                      = 0.62, 0.64, 0.60   consistently UNDER, very flat

A clock error cannot explain this -- it would move both axes together and these
go opposite -- so the discrepancy is per-axis. Candidates, neither measured: a 1 s
burst not completing the angular-acceleration ramp (would under-read; fits roll's
flat 0.62, not pitch's excess), or an unidentified per-axis multiplier. Left as an
open question with the separating test named: 1 s versus 3 s bursts at the same
throttle, where the ramp hypothesis predicts the longer burst reads higher.

Also noted: the roll run correctly REFUSED on a WEAK row pin after the pitch
bursts left the craft tumbled -- and roll is immune to that labelling, which the
guard's own message says, so ALLOW_WEAK_PIN=1 is its documented exception. A guard
that states its own exception is worth having.

docs/re/flight-speed-law.md

@@ -658,3 +658,47 @@ deg/*game*-second cannot be computed from it, and choosing a ratio that makes th
 numbers fit would be circular. The probe now takes clock screenshots at both ends so
 the next run closes it. Data:
 [`captures/pitch-burst-settled-speeds.csv`](captures/pitch-burst-settled-speeds.csv).
+
+
+## Both axes, three settled speeds: shape ✅, absolute scale 🟡
+
+Repeat of the burst design with the HUD clock bracketed (01:01.86 → 02:10.61) and
+roll measured in the same flight. Clock ≈ ×1.26.
+
+| axis | min speed | cruise | max speed | min:max | definition ratio |
+|---|---|---|---|---|---|
+| pitch | 87.0 °/game-s @ 85 | 82.8 @ 308 | 47.0 @ 1 077 | **1.85** | `PitchMinus` 75/40 = **1.88** |
+| roll | 125.0 @ 76 | 119.0 @ 291 | 82.6 @ 1 023 | **1.51** | `Roll` 200/125 = **1.60** |
+
+**The shape is confirmed on both axes** — the rate interpolates between `_Min` (at
+minimum speed) and `_Max` (at maximum speed), matching to **1.6 %** for pitch and
+**5.6 %** for roll. These ratios are **clock-independent**, so they stand regardless
+of the conversion. Pitch's ratio also re-confirms `ly+` = **pitch-minus** (1.88)
+rather than plus (2.14), reproducing the earlier run's 1.82.
+
+**The absolute scale does not match, and not in the same direction:**
+
+```
+pitch   measured / predicted = 1.15, 1.21, 1.07     (consistently OVER)
+roll    measured / predicted = 0.62, 0.64, 0.60     (consistently UNDER, and very flat)
+```
+
+**A clock error cannot explain this** — it would scale both axes the same way, and
+these go opposite. So the discrepancy is per-axis. Two candidates, neither measured:
+
+- a **1-second burst may not complete the angular-acceleration ramp**, which would
+  *under*-read — that fits roll's remarkably constant 0.62 but not pitch's excess;
+- a **per-axis multiplier** applied to the cap that is not yet identified.
+
+Recorded as an open question. The next measurement that would separate them is cheap:
+**1 s versus 3 s bursts at the same throttle** — if the ramp is the cause, the longer
+burst reads higher. Data:
+[pitch](captures/pitch-burst-final.csv) · [roll](captures/roll-burst-final.csv).
+
+## Note on the WEAK-pin guard
+
+The roll run refused to start: after the pitch bursts the craft was no longer level,
+so the row pin came back **WEAK** (margin 0.109). That refusal is correct for pitch
+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.