iris: List::fling with Android's spline physics, and fix the drag-slop scroll jitter

Adds VelocityTracker and a port of AOSP SplineOverScroller's fling curve
(FlingCalculator, cited at the definition) to iris::sense, and wires
List::fling/is_scrolling/cancel_fling/tick_fling through
Selection::drag's release path -- a pan's release now decelerates instead
of stopping dead on the finger lifting, matching IRIS_TODO.md's "swiping
has no momentum" ask. Clamped at the loaded content's start/end and
cancelled by the next touch-down.

Also fixes the scroll jitter DragArbiter's slop release caused: crossing
DRAG_SLOP applied the whole pre-threshold drag (measured from press_start)
in one step, since nothing pans while a gesture might still resolve to a
selection. Now only the excess past DRAG_SLOP is applied on that frame,
the same way Android's own touch handling consumes touch slop rather than
replaying it.

Root-caused by reading DragArbiter's state machine and covered by new
unit tests (fling distance against the closed-form spline result within
1%, cancel-on-touch, start/end clamp, the slop-crossing regression); no
emulator was used this pass, so an on-device trace/feel-check is still
open, and Benchmark v2's four-phase bench_client.rs spec was not
attempted. docs/IRIS.md, docs/IRIS_TODO.md and docs/RUST.md's P0 box
record what's done and what's left.

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

docs/IRIS.md

@@ -8,6 +8,37 @@ capability that moved. Small and trivial changes do not go here.
 An entry gives the date, what changed, why, and a short before/after where
 it helps judge the change without the session that made it. Newest first.
 
+## 2026-09-06: `List::fling`, `VelocityTracker`, `FlingCalculator` (IRIS_TODO.md's "swiping has no momentum")
+
+`iris::widget::List` gained a real fling: `fling(velocity_px_per_s)` starts
+one (cancelled by the next touch-down via `cancel_fling`, or automatically
+once it settles or reaches loaded content's start/end), `is_scrolling()`
+reports whether one is running, and `tick_fling(now: Instant) -> bool`
+advances it and returns whether it is still going -- a caller that owns a
+`RequestRedraw` handle can hand it to the list once via the new
+`set_redraw_handle`, after which `List` re-arms its own next frame while
+flinging with no further polling needed; a caller driving a scripted
+benchmark instead calls `tick_fling` itself in a loop, same as it already
+drives `scroll`.
+
+The physics is `iris::sense::FlingCalculator` + `VelocityTracker`
+(`sense.rs`, beside `DragArbiter`): a port of AOSP `SplineOverScroller`'s
+deceleration curve (the same one Compose's own `ScrollableDefaults.
+flingBehavior()` uses), cited at the definition, so a fling here travels
+the same distance a Compose `LazyColumn` would for the same initial
+velocity. `VelocityTracker` estimates that velocity from the drag's last
+~100ms of samples rather than one frame's last delta. Unit-tested:
+velocity from known samples, fling distance/duration against the closed-
+form spline result (within 1%), cancel-on-touch, and the start/end clamp
+(a fling stops rather than scrolling into content that was never loaded).
+
+Before: a touch-drag panned exactly as far as the finger moved and stopped
+dead on release. After: releasing mid-drag continues scrolling and
+decelerates, matching the muscle memory every other Android scroll view
+already trained. `transcript_ui::selection::Selection::drag` wires this in
+-- a release only flings if the gesture had committed to panning
+(`DragArbiter::is_panning`, new), never a selection or an undecided tap.
+
 ## 2026-09-06: `UiRenderNode::new` returns `Result`, not `Self` (RUST.md's P0 box, phone-crash fix)
 
 `iris_core::UiRenderNode::new(device, queue, config)` now returns