docs: Iris's 11:39 phone report on the 02:07 build, four open items

docs/IRIS_TODO.md

@@ -183,6 +183,48 @@ agent takes them without colliding with that pass's `bench_client.rs`/
   handling is a follow-up, the same shape `List`'s own touch-drag pan
   needed before I3/I5.
 
+## From the phone, 2026-09-06, 11:39 (build delivered 02:07, commit 543f6d9)
+
+Iris's report on the build with the composing-text, tap-vs-swipe and
+atlas-reset fixes, with a screenshot, verbatim. Each is open until an
+agent ticks it here with the evidence.
+
+- [ ] **"The app definitely does not start with keyboard spacing
+  correct. This is how it looks without me doing anything initially."**
+  The screenshot shows the composer bar (the grey band) sitting about
+  two thirds of the way down a 704x1568 screen, with black below it to
+  the bottom, and the transcript ending at "Claude / Results" just above
+  it -- at launch, no keyboard. So the composer's bottom padding, which
+  the 2026-09-06 rebuild tied to the IME/nav-bar inset, is being fed a
+  large value at start on the phone. Suspects, in order: the initial
+  inset delivery on the phone (GrapheneOS, gesture navigation) versus
+  the emulator; `ime_bottom` now carrying a `1`/`0` boolean through a
+  field the composer may still read as pixels or dp; a stale value from
+  before the first `on_insets_changed`. Reproduce with the phone's
+  screen size and density on the emulator before guessing.
+- [ ] **"Swiping still gets caught by the grey bar but keeps working
+  after I go past it."** A pan that starts on the composer is held by
+  the composer until the finger leaves its region, then the list takes
+  over. The tap-vs-swipe fix in `attr.rs` stops the *focus*, but the
+  press frames are still being handled by the field rather than passed
+  to the list from the first slop-crossing frame. The `DragGesture`
+  merge (RUST.md's plan box) should make this one mechanism: once a
+  gesture commits to a pan, the list captures it wherever it began.
+- [ ] **"Flinging still does not work."** Expected on this build: finger
+  flings are dropped by per-widget hit testing, which `DragGesture`'s
+  pointer capture (commit `e12c708`, not yet merged at 02:07) targets.
+  Stays open until verified on her phone, not the emulator.
+- [ ] **"Text still disappears if I leave and come back to the app."**
+  The `GlyphAtlas::clear`/`Textures::reset` fix was verified on the
+  emulator under `force-gles` only; the phone runs Vulkan. So either the
+  reset is not reached on the phone's path (a different surface-
+  lifecycle sequence -- `surface_destroyed`/`surface_created` ordering,
+  or the renderer not being rebuilt but its textures lost), or the CPU
+  glyph cache and the GPU atlas still disagree after it. Needs logging
+  of the renderer lifecycle on the phone build, readable from `adb
+  logcat` when Iris next runs it, since no emulator here has a Vulkan
+  adapter under host GPU.
+
 ## Build
 
 - [x] **Benchmarks**, not unit tests, run on demand (2026-09-05; a

docs/RUST.md

@@ -63,6 +63,14 @@ closes it.
       next tap anywhere panics. Findings 2–5 are `debug_assert!`s on
       invariants, 8 and 10 are the missing tests. Commit the review file
       with the fixes.
+- [ ] **Iris's 11:39 phone report on the 02:07 build** (four items,
+      verbatim in `IRIS_TODO.md`'s "From the phone, 2026-09-06, 11:39"):
+      composer floating two thirds down the screen at launch with black
+      below it; a swipe starting on the composer held until the finger
+      leaves it; no fling (expected, `DragGesture` unmerged); text still
+      lost on app-switch on the phone despite the emulator-verified
+      atlas reset. The first and last are the same class as the next
+      box and go to that agent; the middle two are the merge box's.
 - [ ] **Stale primitives and invisible composer text** — the header drawn
       twice after a keyboard resize, the `Compacted:` row drawn twice on
       Iris's phone, and typed text never appearing (P0 box item 2). All