diff --git a/README.md b/README.md
index b3d6308..6cdd635 100644
--- a/README.md
+++ b/README.md
@@ -198,3 +198,45 @@ started unexpectedly). Not root-caused, and not confirmed to be caused by
 this pass's changes rather than something pre-existing -- worth watching
 for on the phone and reporting back if seen. Full account in
 `docs/RUST.md`'s P0 box in the `ai-app-2` repo (`rustify` branch).
+
+## 2026-09-06, later still: Benchmark v2 (fling/type/keyboard), the header-duplicate finding, the ime-inset finding
+
+**New**: "Run benchmark" now runs the same four-phase script the Compose
+build's v2 does -- fling (8 flings out + 8 back at 12,000px/s through
+`List`'s own new fling, matching Android's real deceleration curve),
+stream (unchanged), type (the same 600-character string, one character
+per 50ms into the real composer, then deleted), and keyboard (five
+show/hide cycles). The report gained a `per phase:` block (frames, late
+%, p50/p90/p99, worst per phase) and the whole-run `frames:` line now
+reads the display's real refresh rate instead of assuming 60Hz.
+
+**The header-duplicate bug from the previous entry: still not fixed.**
+Reproduced reliably this pass (tap the composer field, screenshot after
+the keyboard opens -- the three-button row appears twice, once at its
+real position and once inside the transcript). One real, targeted fix
+was tried and **ruled out**: skipping the header rebuild when the
+status-bar inset hasn't actually changed (since a keyboard toggle also
+re-fires this callback for an unrelated reason) -- the duplicate still
+reproduced identically after that fix, so repeated rebuilding is not the
+cause. Still unexplained; needs either live instrumentation of the
+layout engine's two-phase span placement or a person with the phone.
+
+**Found, and partly explains why the keyboard phase and the
+keyboard-open auto-diagnostics both read "not confirmed" on every
+run so far**: this app's `AndroidManifest.xml` uses
+`windowSoftInputMode="adjustResize"` (needed so the keyboard resizes the
+window instead of panning it off screen), and under `adjustResize`
+`WindowInsets.Type.ime()`'s own inset *amount* is defined to read zero --
+the window already shrank to avoid the overlap that inset would
+otherwise report. Fixed the app to read `WindowInsets.isVisible(ime())`
+(a boolean, unaffected by resize-vs-pan) instead of the numeric inset --
+correct on its own terms, but on this emulator the insets listener still
+never re-fires at all once the keyboard opens (a separate, deeper
+platform behavior tied to this activity not being edge-to-edge, not
+fixed this pass -- changing that is a bigger, riskier window-behavior
+change than the time available justified). So the keyboard phase's "0
+confirmed" and the auto-diagnostics not firing are both still open,
+now for a specific, named reason rather than an unknown one.
+
+Full account, including what was tried and ruled out, in
+`docs/RUST.md`'s P0 box in the `ai-app-2` repo (`rustify` branch).
diff --git a/iris/build/outputs/apk/release/iris-bench-arm64.apk b/iris/build/outputs/apk/release/iris-bench-arm64.apk
index 1f8d69d..31d84ea 100644
Binary files a/iris/build/outputs/apk/release/iris-bench-arm64.apk and b/iris/build/outputs/apk/release/iris-bench-arm64.apk differ