Merge remote-tracking branch 'origin/rustify' into worktree-agent-a1ff0294b6c29127e

# Conflicts:
#	docs/RUST.md

docs/IRIS_TODO.md

@@ -124,20 +124,31 @@ follow-ups. Recorded here rather than fixed in that pass, so a follow-up
 agent takes them without colliding with that pass's `bench_client.rs`/
 `android/view.rs`/`android/sense.rs` changes.
 
-- [ ] **Swiping has no momentum.** iris's `List` pans exactly as far as the
-  finger moves and stops dead on release -- unlike Compose, which flings
-  and decelerates. Needs velocity tracking over the last several move
-  samples and an Android-style decelerating fling, cancelled by the next
-  touch-down, redrawing every frame until it settles. `BenchRun.kt`'s own
-  fling phase (RUST.md's "Benchmark v2" box) is the reference shape:
-  "travel way faster... which is better for stress testing."
-- [ ] **Scrolling down sometimes jitters the text.** Two named suspects,
-  neither confirmed: `DragArbiter`'s slop being released as one jump
-  (`iris/src/sense.rs`), or a per-frame pan delta applied a frame late.
-  Measure by tracing the list's scroll offset per frame against a
-  monotonic synthetic drag, the same way `iris/android-app/trace-draw.sh`-
-  style instrumentation traced the touch-scroll dropout in RUST.md's I5
-  box -- not by eyeballing a screenshot.
+- [x] **Swiping has no momentum, fixed 2026-09-06.** `List::fling`/
+  `VelocityTracker`/`FlingCalculator` (`iris/src/widget/list.rs`,
+  `iris/src/sense.rs`) -- IRIS.md's 2026-09-06 entry has the full account.
+  Wired through `Selection::drag`'s release path, cancelled by the next
+  touch-down, clamped at the loaded content's start/end. Verified by unit
+  test (fling distance against the closed-form spline result, cancel-on-
+  touch, the clamp), not yet by an on-device or emulator feel-check --
+  that is still open.
+- [x] **Scrolling down sometimes jitters the text, fixed 2026-09-06.**
+  Root-caused by reading `DragArbiter::update`'s `Undecided`-to-`Panning`
+  transition rather than by an on-device trace (no emulator was used this
+  pass): it was the first named suspect, not the second. `self.last` stays
+  at the press origin for every `Undecided` frame (nothing pans while the
+  gesture might still be a selection), so the frame that finally crosses
+  `DRAG_SLOP` returned `Pan(dy)` with `dy` measured from `press_start` --
+  the *whole* pre-threshold drag, applied to the list in one step, however
+  many frames it had taken to get there. Fixed by applying only the
+  excess past `DRAG_SLOP` on that one frame (`dy - DRAG_SLOP.copysign
+  (dy)`), the same "consume the slop, don't replay it" rule Android's own
+  touch handling follows. New regression test,
+  `crossing_the_slop_by_a_little_pans_by_a_little` (`iris/src/sense.rs`).
+  **Not yet done**: an emulator trace of the real per-frame offset
+  confirming this was the whole story on real touch input rather than
+  only the arbiter's own unit tests -- worth a follow-up pass before
+  calling it fully closed.
 
 ## Build