docs/IRIS_TODO.md: Iris's 22:16 phone report on the 20303e0 build, four open items with the reading of each

docs/IRIS_TODO.md

@@ -346,6 +346,62 @@ agent ticks it here with the evidence.
   logcat` when Iris next runs it, since no emulator here has a Vulkan
   adapter under host GPU.
 
+## From the phone, 2026-09-06, 22:16 (build from 20303e0, delivered via ai-app-bench 95e25fe)
+
+Iris's report, verbatim, with a screenshot. Phone: Mali-G715 (Vulkan),
+`content_scale: 2.55`, 120Hz. Open until ticked with phone-side evidence.
+
+- [ ] **"Fling still doesn't work."** Second report; the emulator's
+  `ui-trace` swipe flings (verified 2026-09-06 with `render()` counts),
+  a finger on the phone does not. What differs: a real flick at 120Hz is
+  batched by Android into few `MotionEvent`s with *historical* samples
+  (`getHistoricalX/Y/EventTime`), and can be DOWN, one or two MOVEs, UP
+  inside `DRAG_SLOP`'s worth of frames; a `ui-trace` swipe is many
+  evenly-spaced MOVEs. Suspects, in order: `android/sense.rs` reading
+  only each event's final position (the velocity tracker sees two
+  samples, or one); the release path starting a fling only from a
+  gesture already in `Panning`, so a flick that crosses the slop on its
+  last sample is treated as a tap; `ACTION_CANCEL`/pointer-capture
+  delivering no `Drop`. Log the release decision (samples, span,
+  velocity, outcome) at `info` so the next logcat settles it.
+- [ ] **"I can't reopen keyboard by tapping on message box after it
+  already happened once."** The field stays focused after the keyboard
+  is dismissed (back gesture, or the IME's own hide), so `on_press`'s
+  already-focused branch never requests the IME again. Android's
+  `EditText` shows the IME on every tap of a focused field; do the same
+  (`FocusHost`: a tap on a focused field requests the IME, idempotent
+  when it is already shown).
+- [ ] **"Message box does not push up the scroll area."** Since
+  `MainActivity` went edge-to-edge (`e12c708`), `adjustResize` no
+  longer resizes the window, so the app owns the IME inset -- but
+  `ime_bottom` is passed through JNI as the boolean `1`/`0` (the
+  2026-09-06 "(b)" fix), so nothing has the inset's *height* to pad the
+  transcript and composer with. Pass both: `isVisible(ime())` and
+  `getInsets(ime()).bottom` in px; the list's bottom padding and the
+  composer's position follow the height, the visibility drives the
+  boolean the `imePadding` rule in AGENTS.md's "Things that have bitten"
+  describes.
+- [ ] **"Picture is what happens if I leave the app and come back,
+  which completely removes text, and then I tap on the debug info. The
+  textures are definitely getting cooked for some reason after leaving
+  the app and resuming."** Screenshot: every glyph drawn *before* the
+  resume is fragments; the diagnostics text drawn *after* is perfect;
+  the report says `atlas format: Rgba8Unorm, views live: 0`. Reading:
+  `Textures::reset`/`GlyphAtlas::clear` on the new renderer emptied the
+  GPU atlas, but the per-widget cached text primitives (`TextView`'s
+  render cache -- the one `c3cfc67`'s shape counter is keyed on) still
+  carry the old atlas coordinates and are re-submitted as-is; only
+  widgets drawn fresh after the resume shape and upload again. Fix: a
+  renderer rebuild invalidates every cached text render (one
+  generation counter on the atlas, checked at `TextView::render`, or
+  a full-tree redraw with caches dropped), with a `debug_assert!` that
+  no submitted glyph quad references an atlas generation older than the
+  live one. Reproducible on the emulator by forcing a renderer rebuild
+  (home + return, or `surface_destroyed`/`surface_created`) on a screen
+  with text already drawn -- the earlier "verified" home/reopen check
+  screenshotted the emulator's GLES path, where a resume may not
+  destroy the surface at all.
+
 ## Build
 
 - [x] **Benchmarks**, not unit tests, run on demand (2026-09-05; a