iris bench: a report that says what it measured (ai-app-2 9bf714f)

iris APK only. Three corrections to the report, two of them shipped this
morning: `missed vsyncs` counted the bench's own idle pauses as stutter,
`late` counted the wait for the display as cost, and the display reported
60Hz for a run that drew at 120 -- so every late figure was judged
against twice its budget.

Also corrects the frame-rate reading in the previous entry: both runs
sustained ~120.3fps through the motion, so the loop was never dropping
frames and the clock is what made it smooth.

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

README.md

@@ -11,7 +11,49 @@ no enrolment and no permissions.
 
 The rest of this file is the runbook that was delivered with the APKs.
 
-**2026-09-09 (newest): the fling. iris APK only** -- rebuilt from ai-app-2
+**2026-09-09 (later): the report itself was wrong in three places, and
+two of them were mine from this morning.** Rebuilt from ai-app-2
+`9bf714f`, iris APK only. Your run said "now THAT is smooth" and the
+report did not deserve the credit it was taking:
+
+- **`missed vsyncs` was counting the bench sitting idle**, not stutter.
+  276 for the sixteen 300ms rests between flings, 2410 for twelve hundred
+  50ms gaps between keystrokes, 821 for the 50ms between streamed events
+  -- each within a few percent of just multiplying it out. A gap only
+  means anything now if the frame before it had asked for another one.
+- **`late` was counting the wait for the display as if it were cost.**
+  When the app is comfortably ahead, every frame is a little work then a
+  wait for its turn, so the total sits exactly on the budget and `late`
+  becomes a coin toss. It is judged on the work now.
+- **Your display reported 60Hz for a run that drew 3405 frames in 33.1s.**
+  A phone that varies its refresh rate answers with whatever mode it is
+  in when asked, so every `late` figure in that report was judged against
+  twice the budget it should have been. The report now takes the larger
+  of what the display claims and what the run actually sustained, and
+  prints both when they disagree.
+
+**And I misread your frame rate.** "103fps on a 120Hz screen" divided the
+fling phase by its whole duration, rests included; excluding them both
+runs sustained ~120.3fps. So the loop was never dropping frames -- the
+thing that made it smooth is the clock the fling is sampled on, which
+changes no frame count whatsoever. That is precisely why no number in
+either report showed it, and why your eyes were the instrument that
+mattered.
+
+**What is worth reporting back now**: the `fling:` block's `build p50`
+(iris's own work -- it was 0.4ms) and whether `missed vsyncs` is small.
+The `acquire` figure beside it is the display pacing the app and wants to
+be large.
+
+**Streaming is the remaining cost**, and it is not the fold: folding an
+arriving event is 0.35ms and applying it to the widget tree 0.41ms, while
+the frame is 9.5ms on your phone. 401 streamed events move the item count
+from 652 to 654, so nearly every one is a delta into the *same* row --
+the cost is re-shaping one growing message on every delta. Fixing it
+means changing how a row holds its shaped text, which I would rather
+design with you than just do.
+
+**2026-09-09: the fling. iris APK only** -- rebuilt from ai-app-2
 `42d54ee`; the Compose one is unchanged from 2026-09-08.
 
 You reported stuttering when flinging that is much harder to notice with