iris-android-app: the bench observes the fling instead of driving it at 60Hz

The fling phase called List::tick_fling itself every 16ms, so on a 120Hz
phone every second frame redrew a position already drawn -- Iris saw the
benchmark scroll visibly less smoothly than her own finger, and it was
the rig rather than the renderer. A real fling is advanced once per frame
by UiData::tick_animations from the frame callback, so the phase now
starts one the way a gesture does (fling + animate) and polls
is_scrolling to know when it settled. ANIM_STEP_MS becomes POLL_MS,
which is what it always was here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/RUST.md

@@ -7994,10 +7994,25 @@ scroll really is coarser than hers, the difference she sees is the rig
 rather than the renderer, and every frame number the bench has produced was
 measured against a gesture no hand would make.
 
-Fix: drive one step per **real frame**, from the frame callback the
-renderer already runs on, and derive each step's delta from the elapsed
-time it reports rather than from a constant. Pass condition: the bench's
-sample rate matches the display's refresh (say so in the report, next to
-the adapter line, so a number is never read without it), and the report
-states the rate it drove at so an old report cannot be compared to a new
-one by accident.
+**Fixed, 2026-09-08.** The bench does not synthesise touch samples at
+all -- it calls `List::fling(velocity)` and then *drove the fling itself*,
+calling `List::tick_fling` from an async loop every 16ms. A real fling is
+advanced once per frame by `UiData::tick_animations`, from the frame
+callback, which on her phone is 120Hz; so every second frame redrew the
+list at a position it had already drawn. The rig, not the renderer.
+
+`wait_for_fling_settle` now **observes** instead: the phase starts the
+fling the way a finger's release does (`List::fling` **plus**
+`UiData::animate`, the two halves `List::fling`'s own doc says have
+different owners) and polls `is_scrolling()` to know when it is over. So
+the phase measures the same path a gesture takes, at the display's own
+rate. `ANIM_STEP_MS` is renamed `POLL_MS` and its doc says it is how
+often a question is asked, not a cadence anything moves at -- the name
+was half the reason it was used for both. The fling phase's line in the
+report gains `ticked=frame-loop`, so a report from before this cannot be
+compared with one after it by accident; the `frames:` block already
+states the refresh it ran at.
+
+**Not yet confirmed on the phone** -- that needs a build in her hands,
+and the emulator cannot answer it (it is a 60Hz GLES rig, so the defect
+is invisible there by construction).