RUST.md, IRIS.md, IRIS_TODO.md, DECISIONS.md: record I5's frame report and holddrag results

FrameReport gave a real, measured on-device number (frames=34,
janky%=61.76, p50=26.5ms p90=48.0ms p99=98.1ms worst=98.1ms) and
long-press-then-drag-to-select is now confirmed on-device (logcat plus a
screenshot of the highlighted selection). Neither closes I5's box to [x]
yet: the frame number is real but not the clean single 24-swipe loop
comparable to Compose's, because gestures against this checkout's
EMU_GPU=software emulator intermittently delivered zero touch input this
session -- a new, separately named finding (candidate cause: the
emulator's own software rasterisation measured at ~78% of a CPU core
continuously), not yet root-caused. DECISIONS.md's DEFERRED item is
updated with these numbers rather than a decision made here.

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

docs/DECISIONS.md

@@ -66,18 +66,26 @@ 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 with what's now known: iris's Android integration is
-  built and confirmed working on a real device (real server, real
-  scrolling, real touch-drag pan, tap-by-name accessibility — RUST.md's I5
-  box), while Masonry's own touch-scroll on Android was already found
-  entirely absent (E2). What's still missing on **both** sides is a
-  render-time number — not because iris doesn't work, but because
-  `dumpsys gfxinfo` cannot see a `SurfaceView`'s GPU-drawn frames at all,
-  so the `transcript-bench.sh`-style comparison this recommendation wanted
-  produced a real number for Compose (8.96% janky, 99th percentile 150ms,
-  same emulator/session) and none at all for iris. The choice in front of
-  Iris: 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), or wait for iris to grow its own frame-timing
-  instrumentation first so the comparison can be a number rather than a
-  qualitative one. RUST.md's "Recommendation" item 3 has the full account.
+  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.
+  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.