RUST.md, IRIS.md, IRIS_TODO.md, DECISIONS.md: record I5's Android integration and measurements

I5's transcript screen now runs on-device against a real ai-server on
iris-android-app's new transcript-screen feature (extends I2's shell
rather than a third one), with real scrolling, real touch-drag panning
and tap-by-name accessibility all confirmed by screenshot/log evidence.
I4's own emulator-side check (tap-by-name on the tabs demo) closed the
same session, so its box ticks [x] now.

Still [~], not [x]: the render-time number RUST.md's recommendation
wants for iris couldn't be produced this pass, for a precise and
recorded reason rather than a vague one -- dumpsys gfxinfo cannot see a
SurfaceView's own GPU-drawn frames at all (0 frames reported across a
gesture loop that visibly scrolled), and a SurfaceFlinger --latency
fallback gave no per-frame history either on this Android version. The
Compose side of the same loop did produce a real number under identical
conditions (8.96% janky, 99th percentile 150ms), so this is now a
one-sided number rather than a missing one on both sides.

Also found and recorded: the AVD's saved snapshot carries a GPU config
across restarts, so switching between the documented Vulkan boot
recipes needs a cold boot (clearing snapshots/) that the emu wrapper
does not force -- cost three different-looking crashes before the
pattern was the snapshot, not the code.

DECISIONS.md's DEFERRED item is updated with the numbers Iris needs to
weigh the iris-vs-Masonry call; the call itself stays hers.

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

docs/IRIS_TODO.md

@@ -176,14 +176,35 @@ order and what "done" looks like. Tick and date them in place.
   silently dropped. See RUST.md's I5 box for the full account of what
   *was* built (the screen, `SpanStyle`, cross-row selection, the growing
   composer).**
-  - [ ] **Android integration for this screen does not exist yet.** No
-    cdylib/Gradle shell the way `iris-android-app` wraps `tabs-ui` (I2),
-    so `transcript-bench.sh`'s render-number pass condition against the
-    Compose baseline cannot be run. Needs: real `client-core::ApiClient`/
-    `event_stream::follow_session_events` wiring against
-    `app/ui-sandbox.sh --delay` (this crate deliberately fetches nothing
-    itself, `transcript-ui/src/lib.rs`'s doc), a new cdylib + Gradle
-    module, then the bench script pointed at it.
+  - [x] **Android integration for this screen — done, 2026-09-05.**
+    `iris-android-app`'s `transcript-screen` Cargo feature
+    (`transcript_client.rs`) runs this screen against a real `ai-server`
+    through `client-core`, confirmed on-device: real scrolling, real
+    touch-drag panning, tap-by-name on the composer. Two real bugs found
+    and fixed along the way (a missing `INTERNET` permission; a
+    background-thread redraw request that crashed via a `Looper`
+    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] **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