docs: I5's clean scroll comparison between Compose and iris, one session

Same sandbox session content, same emulator, EMU_GPU=software: Compose
(debug, in-app report) 1102 frames/99.0% late/p50 33.8ms/p99 79.5ms vs
iris (release -- debug SIGSEGVs on this emulator) FrameReport 299
frames/94.65% janky/p50 79.1ms/p99 117.8ms (repeat: 233/94.42%/p50
109.3ms). Ticks I5 [x]; states plainly what's not comparable (build
profile forced asymmetric, three different jank definitions, both are
software-rasterised emulator numbers). The two "zero frames" attempts
that preceded the clean runs traced to this session's own script bug
(a cd into /tmp changed which emulator ui-trace targeted), not a
reproduction of the previously-suspected touch-delivery dropout; a
sampler ran the whole session and saw load rise during the gesture
without correlating to any failure. DECISIONS.md's DEFERRED item gets
the same table so Iris can decide iris-vs-Masonry from it -- that
choice is left to her.

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

docs/DECISIONS.md

@@ -66,26 +66,41 @@ marked **DEFERRED** are ones the agent chose not to decide alone.
   pieces and I5's Android integration are all done; next is giving iris
   its own frame-timing report so item 3 below can be decided by a number.
 - **DEFERRED — whether to commit to iris over Masonry for `ai-app`.**
-  Updated 2026-09-05 (later the same day) with what's now known: iris has
-  its own frame-timing report now (`FrameReport`) and a real number from
-  it, captured from a genuine on-device touch-drag —
-  `frames=34 janky%=61.76 p50=26.5ms p90=48.0ms p99=98.1ms worst=98.1ms`
-  — plus a confirmed on-device long-press-then-drag-to-select (logcat and
-  a screenshot of the highlighted selection). It is **not yet the clean,
-  comparable number** the recommendation wants: gestures against this
-  checkout's `EMU_GPU=software` emulator intermittently delivered zero
-  touch input during this session, reproducibly, for a reason named but
-  not yet confirmed (the emulator's own software rasterisation measured
-  at ~78% of a CPU core continuously — a plausible source of input
-  backlog, not yet isolated with a sampler running during a failing
-  gesture). The Compose figure quoted for comparison (8.96% janky, 99th
-  percentile 150ms) is the same one already recorded earlier 2026-09-05,
-  not re-taken this pass, and against a different sandbox session's
-  content — so the two numbers share configuration, not identical data.
+  Updated 2026-09-05 with the clean comparison the recommendation wanted:
+  same sandbox session content, same emulator, `EMU_GPU=software`, one
+  session. Headline numbers (RUST.md's I5 box, "Clean scroll comparison,
+  2026-09-05," has the full table and every caveat):
+
+  | app | build | frames | janky % | p50 | p90 | p99 | worst |
+  |---|---|---|---|---|---|---|---|
+  | Compose (in-app report) | debug | 1102 | 99.0% late | 33.8ms | 50.6ms | 79.5ms | -- |
+  | Compose (`dumpsys gfxinfo`) | debug | 1499 | 21.15% (95.66% legacy) | 32ms | 48ms | 150ms (p99) | -- |
+  | iris (`FrameReport`) | **release** | 299 | 94.65% | 79.1ms | 98.6ms | 117.8ms | 212.6ms |
+  | iris (`FrameReport`, repeat) | **release** | 233 | 94.42% | 109.3ms | 130.8ms | 147.1ms | 150.5ms |
+
+  **Not a clean apples-to-apples reading, stated plainly rather than
+  smoothed over**: iris had to be built **release** (debug `SIGSEGV`s on
+  this emulator's Vulkan loader, I4's finding) against Compose's mandated
+  **debug** build, so this asymmetry likely *understates* iris's gap
+  rather than the reverse; the three frame-time sources measure different
+  things (Compose's own phase accounting vs. Android's HWUI deadline-miss
+  definition vs. iris's redraw-start-to-present window, the last of which
+  `dumpsys gfxinfo` cannot see at all for iris's `SurfaceView`); and both
+  figures are emulator numbers under software rasterisation, which
+  Compose's *own* in-app report shows already costs 20-34ms/frame in
+  `swap`+`gpu` alone under this GPU mode, so a same-mode iris number well
+  above 16.7ms was expected going in for either app. A second pair under
+  `-gpu host` was not taken this pass. The earlier session's suspected
+  intermittent touch-delivery dropout was **not reproduced** this pass —
+  the zero-frame results this time traced to this pass's own script bug
+  (a `cd` that changed which emulator `ui-trace` targeted), not the
+  emulator; a CPU-load rise during the gesture was observed by a sampler
+  running throughout, but did not correlate with any failure, so the
+  original candidate is neither confirmed nor ruled out.
   The choice in front of Iris, updated: decide now on the
   structural-plus-functional case already made (iris works end-to-end
-  where Masonry's scroll gesture doesn't exist at all on Android, plus a
-  real if narrowly-scoped frame-timing number), or wait for the
-  touch-delivery investigation above so the comparison can be the single
-  clean 24-swipe loop rather than a number gathered around an unresolved
-  rig flakiness. RUST.md's "Recommendation" item 3 has the full account.
+  where Masonry's scroll gesture doesn't exist at all on Android) plus
+  this table — reading the two build profiles and three jank definitions
+  with the caveats above rather than as a single number — or ask for a
+  same-profile, same-GPU-mode rerun first. RUST.md's I5 box has the full
+  account.