re(flight): rows pinned by world-Y, and nothing yaws -- the yaw gap is answered

The probe now pins which non-forward row is up and which is right, instead of
taking the D3D convention on faith:

    row world-Y means: [0.469, 0.883, -0.000]   forward = row 2
      -> up = row 1, right = row 0   CONFIDENT

That is the OPPOSITE of the assumption the previous run used, so that run's yaw
and pitch columns were swapped -- under the correct labels its ly+ reading of
154.1 deg/wall-s is PITCH, which is what a left-stick Y should do.

Measured with the unknown inputs FIRST, each passing a liveness check:

    rx  0.0  0.0  0.0      ry  0.0  0.0  0.0
    LB  0.0  0.0  0.0      RB  0.0  0.0  0.0
    lx  roll 209.8         ly  pitch 154.1

These zeros are trustworthy where the previous run's were not: the craft was
verified alive between inputs, and the probe aborted the moment it stopped moving
rather than reporting the clean zeros a destroyed craft produces (it did abort,
after lx+, which is why lx/ly are carried from the earlier run rather than
re-measured).

So NO PAD INPUT YAWS THE CRAFT. AV_Yaw_* (45/25) exists in the definitions but
nothing on the right stick or the shoulders drives it, which upgrades the old
"yaw: no input found" from a failure to find one into a measurement that the
remaining candidates do nothing. The natural reading is that yaw is a consequence
of banking rather than a commanded axis.

Not covered, and not claimed: the d-pad (tactical map) and the face buttons
(fire/weapon select). Neither is a plausible flight axis; neither was measured.

docs/re/captures/axis-probe-rows-pinned.csv

@@ -0,0 +1,5 @@
+input,roll_deg_s,yaw_deg_s,pitch_deg_s
+rx+,0.0,0.0,0.0
+ry+,0.0,0.0,0.0
+LB,0.0,0.0,0.0
+RB,0.0,0.0,0.0

docs/re/flight-speed-law.md

@@ -458,3 +458,49 @@ Method note: the tell that the *old* result was broken was two conditions agreei
 too well (pitch ≈ roll). The tell that this one is sound is that they now **disagree
 in the direction the definitions predict**, on two independently-bracketed phases.
 Data: [`captures/roll-about-forward-axis.csv`](captures/roll-about-forward-axis.csv).
+
+
+## Which input drives which axis — and the yaw answer ✅
+
+`tools/re-capture/axis_probe.py` holds one channel at a time (file pad, so every
+other channel is exactly zero) and decomposes the result into **all three** rotation
+components at once, rather than measuring one axis through a row that moves under any
+rotation — the flaw that once made roll and pitch produce identical numbers.
+
+**The row labelling is measured, not assumed.** `entities2` pins row 2 = forward
+against velocity; the probe pins the other two by comparing **world-Y** in flight:
+
+```
+row world-Y means: [0.469, 0.883, -0.000]   forward = row 2
+  -> up = row 1, right = row 0   CONFIDENT
+```
+
+That is the **opposite** of the D3D convention an earlier run assumed, which means
+that run's *yaw* and *pitch* columns were swapped — under the correct labels its
+`ly+` reading of 154.1 °/wall-s is **pitch**, which is what a left-stick Y axis
+should do.
+
+| input | roll | yaw | pitch | |
+|---|---|---|---|---|
+| `rx` right-stick X | 0.0 | 0.0 | 0.0 | nothing |
+| `ry` right-stick Y | 0.0 | 0.0 | 0.0 | nothing |
+| `LB` | 0.0 | 0.0 | 0.0 | nothing |
+| `RB` | 0.0 | 0.0 | 0.0 | nothing (it is the nose gun) |
+| `lx` left-stick X | 209.8 | ~0 | ~10 | **roll** |
+| `ly` left-stick Y | ~0 | ~0 | 154.1 | **pitch** |
+
+These zeros are **trustworthy**, unlike the previous attempt's: the four unknown
+inputs were measured *first*, each passing a liveness check, and the run aborted the
+moment the craft stopped moving instead of reporting the clean zeros a destroyed
+craft produces.
+
+**So no pad input yaws the craft directly.** `AV_Yaw_*` (45/25) exists in the unit
+definitions but nothing on the right stick or the shoulders drives it — the earlier
+❔ *"no input found"* is upgraded from "we could not find one" to **"the remaining
+candidates measurably do nothing"**. The natural reading is that yaw is a
+*consequence* of banking rather than a commanded axis, which a reimplementation
+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).