iris bench: the 22:16 report's four items, from ai-app-2 ba0f2ea

Keyboard reopen and the IME's height are fixed and confirmed on the
emulator; the fling had three faults behind it (batched samples never
read, nothing advancing an animation between input events, and two wrong
constants that made a flick coast for 45 seconds once it finally moved)
and needs the phone to settle, with the logcat line to send named in the
README; the resume/texture fix has a test but no device that can
reproduce the state it fixes.

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

README.md

@@ -295,3 +295,53 @@ folder and never reached this repo:
 
 Not in this build: markdown block styling (headings, highlighted fences, lists, tables, links)
 and tool-call cards, which landed on `rustify` after it -- next build.
+
+## 2026-09-07: the keyboard reopens, the composer moves for the IME, and a fling actually flings
+
+From `ai-app-2` commit `ba0f2ea` on `rustify` (`iris-bench-arm64.apk`, arm64 release,
+minSdk is 29 now). This build answers all four items of your 22:16 report.
+
+- **"I can't reopen keyboard by tapping on message box."** Fixed. Dismissing the keyboard
+  leaves the field focused, and the only code path that asked for the keyboard was the one
+  that ran when a field *became* focused, so it never ran again. A tap on an already-focused
+  field asks for it now, exactly as Android's own `EditText` does. Checked on the emulator
+  both ways: with the fix the second tap opens it, without it the second tap does nothing.
+  Swiping over the composer still summons nothing, which is the thing this could have broken.
+- **"Message box does not push up the scroll area."** Fixed. The keyboard's *height* was being
+  sent across to Rust as the boolean 1, so nothing had a number to pad by. Height and
+  visibility are two separate values now. On the emulator the composer rises by exactly the
+  keyboard's height and the transcript shrinks to match.
+- **"Fling still doesn't work."** Three separate faults, all fixed, and **this is the one to
+  test hardest** because the emulator cannot reproduce your phone's input timing.
+  1. A fast flick at 120Hz arrives as one or two events with the in-between positions batched
+     inside them, and we were reading only the last position -- so the speed came out as zero.
+     Every batched sample is replayed now, each with its own timestamp.
+  2. Nothing in iris advanced a fling between input events at all. The benchmark drove its own
+     fling loop, which is why the bench "flung" and a finger never did. Widgets can animate now.
+  3. Once flings finally moved, one lasted 45 seconds: two constants were wrong (a hardcoded
+     display density, and the scroll friction used where Android uses its own 0.84 tuning
+     number -- a factor of 56 inside an exponential). A flick now coasts for the time Android's
+     own formula says: 1.6s for a hard flick, 0.6s for a gentle one.
+
+  **If it still does not fling on your phone**, the one line that settles it is
+  `adb logcat | grep "iris drag release"` -- please send it. `samples=1` or `span=0.0ms` means
+  the batched samples are not reaching us on your device; a sensible span with `v=` in the
+  thousands and `outcome=Released(Some(...))` means the gesture is measured correctly and
+  whatever is wrong is after that point. `outcome=Tapped` means the flick never counted as a
+  drag at all.
+- **"The textures are getting cooked after leaving the app and resuming."** Fixed in
+  `ba2afba`, with a headless test, but **not confirmed on a device**: no emulator here has a
+  Vulkan adapter and the GLES path may not destroy the surface at all, so this one needs your
+  phone. The cause was one cache deeper than the last build's fix reached -- each text widget
+  kept its own laid-out glyphs with the *old* atlas's coordinates and re-submitted them
+  verbatim, which is why only text drawn after the resume looked right. The atlas carries a
+  generation now and a cleared atlas invalidates every cached layout at once.
+
+Also in this build, both found while checking the above: a tap on the composer aborted every
+debug build (a fixed bound on how deep a widget can nest was 16 and the composer is 17 deep --
+in a release build like this one it did not crash, it silently drew and hit-tested that part of
+the tree in the wrong place), and the app now requires Android 10 or newer, because the
+per-sample touch timestamps the fling fix needs are API 29.
+
+Still not fixed, and unrelated to any of the above: the composer bar's grey background is not
+drawn on this build, so the transcript shows through behind the message field.