docs: record the keyboard-wipe fix, the dp unit and the header fix

docs/IRIS.md's 2026-09-06 entry (public API), docs/LAYOUT.md's "Density:
Len::dp" design section, IRIS_TODO.md's density-unit item ticked, and
docs/RUST.md's P0 box gets the investigation: the keyboard-wipe
hypothesis and confirmation, the blur root cause and why the dp unit
turned out to be the same fix, the header cause, and what remains
unverified (an emulator screenshot of the keyboard fix, and Iris's real
phone).

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

docs/RUST.md

@@ -4438,6 +4438,84 @@ device.
       apk/release/iris-bench-arm64.apk`; that repo's own README gained a
       dated entry. Still not confirmed on Iris's actual phone.
 
+      **Redelivered again, 2026-09-06, a later pass.** Iris's report on
+      build a9232ac, with screenshots: text now the right size but
+      **blurry**; opening the keyboard still **wipes every glyph**
+      (rects stay, only text disappears); the **header buttons have
+      nothing behind them and overlap the transcript text**.
+
+      **1. The keyboard wipe.** Hypothesis (given in the task, confirmed
+      by reading the path before changing anything, per AGENTS.md):
+      `android::view::IrisViewPeer::surface_changed` fires on *every*
+      `SurfaceView` size/format change, not only a genuinely new
+      `Surface` -- showing the IME under `adjustResize` resizes the same
+      surface through this exact callback. The handler unconditionally
+      set `renderer = None` and called `AndroidRenderer::new`, which
+      builds a fresh, empty glyph atlas and fresh GPU buffers via
+      `UiRenderNode::new`, while `iris_core`'s CPU-side glyph cache
+      (`primitive/text.rs`) kept the atlas UV coordinates it had already
+      handed out against the *old* atlas -- every glyph then drew from a
+      rectangle pointing into a texture that had just been recreated
+      empty. Confirmed by reading `AndroidRenderer::resize` (already
+      existed, already did none of that -- only `surface.configure` and
+      the window uniform) against what `surface_changed` was actually
+      calling instead. **Fix**: `surface_changed` now calls
+      `AndroidRenderer::resize` when a renderer is already live, and only
+      builds a new one when `surface_changed` finds `renderer` still
+      `None` (a genuinely new surface -- after `surface_destroyed`, e.g.
+      backgrounding). Not independently re-verified against a forced IME
+      resize on this pass's emulator (no display keyboard exercised
+      end-to-end here); the reasoning is a direct code read plus the
+      existing `resize` path already being surface-only, not a
+      screenshot diff -- **the next agent with emulator time should do
+      the before/after screenshot this box originally asked for.**
+
+      **2. The blur.** Root cause: the P0 fix that made text the right
+      *size* (dividing the whole window into a "logical" space, then
+      letting the shader's NDC mapping stretch it back onto the real
+      framebuffer) rasterised each glyph at the small, pre-stretch size
+      and then displayed it stretched onto more physical pixels than it
+      had texels for. **Fix, and the density-independent length unit
+      Iris asked for the same day (IRIS_TODO.md) turned out to be the
+      same fix**: `Len::dp`, resolved against a `density` now carried on
+      `UiRenderState`/`Painter`, replaces the global stretch -- window
+      size, touch and insets are physical pixels throughout again
+      (`WindowInsets`, renamed from `LogicalInsets`), and
+      `TextBuffer::shape` multiplies `font_size`/`line_height` by density
+      before handing them to parley, so the atlas rasterises at the
+      display's real physical resolution. Full design in docs/LAYOUT.md's
+      "Density: `Len::dp`" section and the public-API summary in
+      docs/IRIS.md's 2026-09-06 entry.
+
+      **3. The header.** Only each button's own `rect(...)` painted
+      anything, so the gaps between/around them and the status-bar strip
+      above showed `CLEAR_COLOR` (black) one layer back, and the row's
+      reserved height was three `abs` (now-physical-pixel) button boxes
+      -- smaller than the dp-correct size the transcript below uses,
+      which is what read as "overlap" once the two disagreed. Fixed with
+      a `HEADER_SURFACE` rect stacked behind the whole row and every
+      header size moved onto `dp(...)`.
+
+      **4. Keyboard diagnostics, so Iris can report back even if a
+      keyboard-triggered regression persists.** `on_insets_changed` now
+      edge-triggers ~500ms after `ime_bottom` becomes non-zero, capturing
+      the same report the on-screen Diagnostics button produces, logging
+      it, copying it to the clipboard unprompted, and showing it in a new
+      plain-view overlay (`IrisView.showDiagnosticsOverlay`, Copy/Close)
+      that draws independently of iris's own renderer.
+
+      **Verified this pass**: `cargo fmt --all`, `cargo clippy --workspace
+      --all-targets` and `cargo clippy` on `android-app` (both `-D
+      warnings`, zero beyond the pre-existing `tabs-ui` unused-dependency
+      and wgpu future-incompat notices), `cargo test --workspace` (all
+      passing), `cargo ndk -t arm64-v8a check`/`clippy` for both the
+      `transcript-screen bench` feature set. **Not verified this pass**:
+      an actual emulator run of `run-bench.sh`, a forced-resize
+      before/after screenshot for the keyboard fix, or anything on Iris's
+      real phone -- next agent with emulator/phone time should confirm
+      all three and the two-density crispness check IRIS_TODO.md's unit
+      item asks for.
+
 - [ ] **P1 — session screen parity.** History paging backward (with the
       page-boundary healing `client-core` does not have yet, below),
       `TranscriptSource`-backed cache/server stitching, jump-to-latest,