docs: the fling's "before" velocity is what velocity_reference.py prints, 12250 and 12500

docs/REVIEW-2026-09-07.md's D5. Four places quoted 11750 px/s as the old
average estimator's answer -- for `flick-120hz.touch` *and* for the
press-plus-one-move-frame set, which are different sample sets, and one
number in both rows is the tell. `iris/benches/velocity_reference.py`,
which the same section says every number below it comes from, prints
12250 for the recording and 12500 for the two-sample set, and
`sense.rs:1406` already had the 12250.

Half of where 11750 came from is recoverable and is written down beside
the table: it is the recording's 196 px over 16.68 ms, a 60 Hz frame
rather than the 16 ms span the file itself records. That explains the
flick row; the other row was copied from it. The 1.30x ratio derived from
it becomes 1.24x.

Also settles the second disagreement about the same experiment (the
review's rule finding on the negative control): `sense.rs`'s doc comment
claimed reverting `velocity` to total-over-span fails "exactly this one,
the flick recording, and phone_screen.rs" while RUST.md said seven. Run
again today with the revert in place: seven in `-p iris` (the flick
recording, the accelerating flick, the horizon, the stopped finger, the
minimum sample count, both `drag_gesture` flick tests) plus
`phone_screen.rs`'s flick, everything else green. RUST.md was right and
the comment now says the same thing.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/RUST.md

@@ -1028,19 +1028,31 @@ every number the tests assert. On the phone's own recording
 
 | sample set | shipped (average) | Compose (Lsq2) |
 | --- | --- | --- |
-| `flick-120hz.touch` | 11750 px/s | **15250 px/s** |
+| `flick-120hz.touch` | 12250 px/s | **15250 px/s** |
 | steady drag, 5px/10ms | 500 px/s | 500 px/s |
 | accelerating flick, deltas doubling | 1080 px/s | **2445 px/s** |
 | old fast burst then 1px/10ms | 9182 px/s | 100 px/s |
 | stopped 48ms, then released | 2533 px/s | 0 px/s |
-| press + one move frame | 11750 px/s | 0 px/s |
+| press + one move frame | 12500 px/s | 0 px/s |
 
-The recording understates the change (1.30x) because it is only 16ms
+The recording understates the change (1.24x) because it is only 16ms
 long; the accelerating set (2.26x) is the shape of a real finger flick
 and is what Iris was feeling. The last three rows are the cases an
 average gets not just low but *wrong*: it flings from a standstill, and
 it flings from two points that describe no curve.
 
+**Corrected 2026-09-07** (docs/REVIEW-2026-09-07.md's D5): the first and
+last rows of the "shipped" column, and the 1.30x, read 11750 px/s -- one
+number in two rows for two different sample sets, which is the tell. The
+script prints 12250 for the recording (196 px over its own 16 ms) and
+12500 for the press-plus-one-move set (100 px over 8 ms). Where 11750 came
+from is only half recoverable: it is 196 px over 16.68 ms, i.e. the
+recording's travel divided by a **60 Hz** frame rather than by the span
+the file itself records, which explains the flick row and does not explain
+the other one -- that one was copied. The rule at the top of this section
+stands: these numbers come from `velocity_reference.py`, and a
+disagreement is fixed by running it, not by running the Rust.
+
 **Tests.** Eight in `sense::velocity_tracker_tests`, two rewritten in
 `sense::drag_gesture_tests` (three samples is the fewest that can fling;
 one move frame answers 0, as Compose does), and `phone_screen.rs` now