docs: the 22:16 report reconciled with what was actually run

RUST.md's "Shell lost" section and IRIS_TODO.md's matching paragraph both
said item 4's fix was written but never built or tested. It was committed
in ba2afba with its test passing, so both were stale the moment that
landed and read as if nothing had been run at all.

Replaced with one section per item, saying what was fixed, what was
measured on this checkout's emulator and what the phone still has to
settle: items 2 and 3 ticked with their numbers, item 4 ticked on the code
with phone confirmation still owed (no Vulkan adapter here), item 1 left
open with the exact logcat line for Iris to look at. The two pre-existing
faults found on the way -- the 16-deep move chain and the API-29 JNI calls
-- are recorded where the next reader will hit them.

IRIS.md gains the public-surface entry: `Widget::tick`,
`UiData::animate`/`tick_animations`, `FlingCalculator`'s density and
coefficient, and `MOVE_CHAIN_LIMIT`.

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

docs/IRIS_TODO.md

@@ -351,7 +351,13 @@ agent ticks it here with the evidence.
 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
+- [ ] **"Fling still doesn't work."** *(Three defects fixed 2026-09-07;
+  open until the phone says so. **The line to look for:**
+  `adb logcat | grep "iris drag release"` -- `samples=1` or `span=0.0ms`
+  means the batched samples are not reaching the tracker there, while a
+  sensible span with `v=` in the thousands and
+  `outcome=Released(Some(…))` means the gesture was measured right and
+  anything still wrong is downstream.)* 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
@@ -364,14 +370,24 @@ Iris's report, verbatim, with a screenshot. Phone: Mali-G715 (Vulkan),
   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
+- [x] **"I can't reopen keyboard by tapping on message box after it
+  already happened once."** *(Fixed 2026-09-07: `attr.rs`'s already-
+  focused branch calls `focus_gained` on a tap inside `DRAG_SLOP`.
+  Emulator: first tap `mInputShown=true`, back gesture, second tap
+  `mInputShown=true`. Negative control with that one call removed leaves
+  the second tap at `false`; a horizontal and a vertical swipe over the
+  focused field both leave it at `false`, so the earlier "swiping over
+  the input bar brings up the keyboard" has not returned.)* 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
+- [x] **"Message box does not push up the scroll area."** *(Fixed
+  2026-09-07: height and visibility are two JNI values now. Emulator:
+  `iris insets: … bottom=883 ime_bottom=883 ime_visible=true`, composer
+  box `31,2277..1048,2329` -> `31,1457..1048,1509`, and the list follows
+  because it is `rest(1)` in the same `Span`.)* 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
@@ -381,7 +397,7 @@ Iris's report, verbatim, with a screenshot. Phone: Mali-G715 (Vulkan),
   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,
+- [x] **"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
@@ -402,6 +418,41 @@ Iris's report, verbatim, with a screenshot. Phone: Mali-G715 (Vulkan),
   screenshotted the emulator's GLES path, where a resume may not
   destroy the surface at all.
 
+  **Fixed in `ba2afba`, with `clearing_the_atlas_re_renders_cached_text_
+  instead_of_reusing_it` run and passing (2026-09-07). Ticked on the
+  code; still wants phone-side confirmation** -- no emulator here has a
+  Vulkan adapter, and the GLES path may not destroy the surface at all,
+  so the emulator cannot reproduce the state Iris photographed.
+
+  The reading above is right and the mechanism is one step narrower than
+  "cached text primitives". `IrisViewPeer::surface_changed`
+  (`iris/src/android/view.rs`) *does* already force a full-tree redraw
+  after a rebuild: it calls `render.resize(...)` unconditionally, which
+  sets `UiRenderState::resized`, which makes the next `update` take
+  `redraw_all` rather than `redraw_updates`. So every widget's `draw`
+  really does run again after the resume. What survives it is one cache
+  further in: `TextView::render` (`iris/src/widget/text/mod.rs`) returns
+  its cached `RenderedText` whenever the wrap width, buffer and attrs are
+  unchanged -- true of every pre-resume row -- so `TextData::place` is
+  never reached, nothing is re-rasterised into the fresh atlas, and the
+  *old* atlas's `uv_min`/`uv_max`/`layer` are re-submitted verbatim. Only
+  text whose content changed after the resume (the diagnostics pane Iris
+  tapped) re-shapes, which is exactly the split in her screenshot.
+  `Painter::glyphs` has one call site in the whole workspace, that one,
+  so there is no second holder of a `RenderedText` to fix.
+
+  The fix, in `ba2afba`: `GlyphAtlas::generation`, bumped by
+  `GlyphAtlas::clear`; `RenderedText::generation` recording which atlas
+  its glyphs were placed against; `Painter::atlas_generation()`;
+  `TextView::render`'s cache key gains it; and a `debug_assert_eq!` in
+  `Painter::glyphs` that a submitted quad's generation is the live one.
+  Headless test
+  `clearing_the_atlas_re_renders_cached_text_instead_of_reusing_it`
+  (`iris/src/widget/text/mod.rs`): draw, `atlas.clear()`, `resize`, draw
+  again, and assert the atlas holds the same glyph count again -- it
+  stays at 0 without the fix, because the cache short-circuits before
+  `place`.
+
 ## Build
 
 - [x] **Benchmarks**, not unit tests, run on demand (2026-09-05; a