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/IRIS_TODO.md

@@ -1023,7 +1023,7 @@ do not duplicate it there.
   immediately after releasing the flick (the slow down seems
   correct)."** Done; RUST.md's "The fling started too slow" has the
   derivation and the table. On `flick-120hz.touch` the release velocity
-  goes from **11750px/s to 15250px/s**, and on an accelerating flick --
+  goes from **12250px/s to 15250px/s**, and on an accelerating flick --
   the shape a real finger makes, and what the recording is too short to
   show -- from 1080 to 2445px/s. The curve was right; `VelocityTracker`
   was averaging total motion over the sample span, which cannot tell an

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

iris/src/sense.rs

@@ -1582,8 +1582,14 @@ mod velocity_tracker_tests {
     /// the release: Compose reads 2445px/s where the average reads 1080,
     /// so a flick started at 44% of the speed the finger asked for. This
     /// is the test the old estimator fails and the steady drag above does
-    /// not -- reverting `velocity` to `total / span` fails exactly this
+    /// not. Reverting `velocity` to `(newest - oldest) / span` fails seven
-    /// one, the flick recording, and `phone_screen.rs`.
+    /// -- this one, the flick recording, the horizon, the stopped finger,
+    /// the minimum sample count and both `drag_gesture` flick tests, plus
+    /// `phone_screen.rs`'s flick -- and leaves everything else green. Rerun
+    /// 2026-09-07 (docs/REVIEW-2026-09-07.md): this comment used to say
+    /// "exactly this one, the flick recording, and `phone_screen.rs`",
+    /// which disagreed with docs/RUST.md's count of the same experiment.
+    /// Seven is what the run prints; RUST.md was right.
     #[test]
     fn an_accelerating_flick_reads_its_speed_at_the_release() {
         const ACCELERATING: [(u64, f32); 6] = [
@@ -2186,7 +2192,7 @@ mod drag_gesture_tests {
     /// Compose answers 0 here (`minSampleSize = 3`) and so does this, so
     /// the release is a pan that flings nothing rather than a pan that
     /// flings at a guessed speed. Before 2026-09-07 the average answered
-    /// 11750px/s from the same gesture.
+    /// 12500px/s from the same gesture.
     #[test]
     fn a_flick_delivered_as_one_move_frame_carries_no_velocity_to_fit() {
         let mut ui = UiData::default();

iris/transcript-fixture/tests/phone_screen.rs

@@ -52,7 +52,7 @@ fn a_recorded_flick_releases_with_a_velocity_and_flings_the_list() {
     // code. Negative because the flick runs *down* the screen and
     // `Selection::drag` flings the list by `-v` (see its `Released` arm).
     // The 2026-09-07 before/after: the old average estimator read
-    // -11750px/s here, which is the fling Iris reported as too slow.
+    // -12250px/s here, which is the fling Iris reported as too slow.
     assert!(
         (velocity + 15_250.0).abs() < 20.0,
         "expected ~-15250px/s from velocity_reference.py, got {velocity}"