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/IRIS_TODO.md

@@ -186,25 +186,52 @@ order and what "done" looks like. Tick and date them in place.
     requirement, fixed by routing through `View::post_delayed` — see
     `IRIS.md`'s `Tasks::redraw_handle` entry). See RUST.md's I5 box,
     "The Android integration, done 2026-09-05" for the full account.
-  - [ ] **A render-time number for iris, comparable to Compose's
-    `transcript-bench.sh` report.** `dumpsys gfxinfo` cannot see a
-    `SurfaceView`'s own GPU-drawn frames at all (confirmed: 0 frames
-    reported across a gesture loop that visibly scrolled), and a
-    `dumpsys SurfaceFlinger --latency` fallback returned no per-frame
-    history either on this Android version's BLAST compositor. What's
-    needed is frame-timing instrumentation inside iris itself — a report
-    the way `UiRenderState::take_counters`/`AccessTree::take_rebuilds`
-    already expose counters, extended to timing. This is the one number
-    RUST.md's recommendation (item 3) is still waiting on.
-  - [ ] **Long-press-then-drag-to-select was not independently driven
-    on-device.** `ui-trace`'s two gesture primitives (`tap`, `swipe X1 Y1
-    X2 Y2 MS`) cannot produce "hold stationary for `LONG_PRESS`, then drag
-    without lifting" — `swipe` interpolates motion across its whole
-    duration from the start. Needs either a new `ui-trace` action (a
-    genuine hold-then-drag primitive) or raw multi-step `MotionEvent`
-    injection. `DragArbiter`'s own unit tests already cover this exact
-    sequence against a synthetic clock (`iris/src/sense.rs`), which is why
-    this is "not independently driven on-device" rather than "unverified."
+  - [x] **A render-time number for iris, comparable to Compose's
+    `transcript-bench.sh` report — instrumentation done and a real number
+    obtained, 2026-09-05 (later the same day); the clean comparable loop
+    is not.** `iris_core::FrameReport` (`iris/core/src/render/
+    frame_report.rs`, `IRIS.md`'s new entry) times every frame from
+    `render()`'s redraw start to after `queue.submit`+`present()`, exposed
+    as two named on-screen controls ("Frame report", "Reset frame
+    report"). Driven against a real on-device touch-drag it read
+    `frames=34 janky%=61.76 p50=26.5ms p90=48.0ms p99=98.1ms
+    worst=98.1ms` — real, not inferred, but accumulated across several
+    gestures rather than one clean 24-swipe loop, because of the new
+    finding below. See RUST.md's I5 box, "Update, 2026-09-05, later the
+    same day" for the full account.
+  - [ ] **New, 2026-09-05: intermittent touch delivery to iris's
+    `SurfaceView` under this checkout's `EMU_GPU=software` emulator.**
+    The same swipe coordinates, confirmed (by scanning a screenshot
+    column for the first non-black pixel) to sit over real row text,
+    sometimes produced 30+ real frames and a screenshot diff and
+    sometimes produced zero of either, across otherwise-identical
+    `ui-trace` invocations. Not the already-understood "already at that
+    scroll edge" case (reproduced with content confirmed taller than the
+    viewport, in both directions). Leading candidate, not yet confirmed:
+    this checkout's emulator was independently observed at ~78% of one
+    CPU core, continuously, while idle on-screen — SwiftShader's software
+    rasterisation is CPU-bound by design, and a synthetic touch competing
+    with that load for delivery is plausible but unmeasured *during* a
+    failing gesture (the standing rule against diagnosing from
+    after-the-fact measurements applies here). Needs a sampler (load,
+    `dumpsys input`, a `-i 0` `ui-trace` capture) running while a failing
+    gesture is driven, and ideally a comparison under `-gpu host` (real
+    Vulkan) to see whether it is specific to software rendering. This is
+    what blocks the clean, comparable 24-swipe loop above.
+  - [x] **Long-press-then-drag-to-select — confirmed on-device, 2026-09-05
+    (later the same day).** `ui-trace` gained a `holddrag X1 Y1 X2 Y2
+    HOLD_MS MOVE_MS` action (`emulator-tools`, additive, extends the same
+    `MotionEvent`/`injectInputEvent` mechanism `swipe` already used):
+    press, hold past `LONG_PRESS`, move, release, as one continuous touch.
+    Driven against a real row (`holddrag 300 1850 300 2050 600 300`) it
+    produced `iris selection: begin at row ...` then a sequence of
+    `iris selection: extend to row ...` log lines
+    (`transcript-ui/src/selection.rs`, a new small `log` dependency since
+    selection has no accessibility label of its own yet — see the next
+    item), and a screenshot taken right after shows the expected
+    highlighted selection spanning multiple rows. `DragArbiter`'s own
+    unit tests already covered this sequence against a synthetic clock;
+    this is the first time it has been driven by a real device touch.
   - [x] **Touch-drag panning over a row's own rendered text — done,
     2026-09-05.** `row.rs` used to register `CursorSense::click_or_drag()`
     on each row's `TextEdit` for cross-row selection; `TextEdit::draw`'s