diff --git a/README.md b/README.md
index c1b900b..8d412dd 100644
--- a/README.md
+++ b/README.md
@@ -345,3 +345,73 @@ 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.
+
+## 2026-09-07, later: the fling curve was a straight line, and the keyboard was one build setting
+
+`iris-bench-arm64.apk` rebuilt from ai-app-2 `rustify` commit `4274b8b`.
+This is the build for your three lines on the last one.
+
+**"It seems to just be linear velocity with an abrupt stop."** It was
+exactly that, and not approximately -- the curve iris used to shape a
+fling returned a straight line for every input. Android's own deceleration
+curve is built by a loop that solves one cubic and samples a *different*
+one; iris had both halves solving and sampling the same one, which made the
+two tables it builds identical, and the lookup that reads one against the
+other then cancels out to "distance is proportional to time". So a flick
+coasted at its release speed for the whole (correctly computed) duration
+and then stopped dead at the end of it.
+
+It is ported exactly now, from Android's `OverScroller.java` and from
+Compose's own copy of the same curve, which agree line for line -- so a
+fling here should travel and slow the way every other Android scroll view
+does. On the emulator a released 3750px/s now decelerates
+3746 -> 2624 -> 1834 -> 1144 -> 752 -> 449 -> 243 -> 83px/s across 32
+frames, where before it would have held 3750 for all of them. **What to
+look for**: a flick should visibly slow before it stops, and a longer flick
+should slow over a longer distance. Two things that also should hold, both
+checked here: a flick into the top or bottom of the transcript stops there
+without bouncing, and putting a finger down during a fling stops it dead.
+
+Worth saying because it is the reason this took two builds: every test the
+fling code had compared it against itself -- is it monotonic, is the sign
+right, does it add up to the total -- and **all of them pass on a straight
+line**. The expected numbers are now generated by a separate transcription
+of Android's source that does not share a line of code with iris.
+
+**"The keyboard raising up does not push things upwards."** This one was a
+single line of the bench app's build file: it declared it targeted Android
+14, while the real app (the Compose one, whose keyboard does push its
+transcript up on your phone) declares 17. Below the Android 15 target line
+a window keeps the old behaviour, where the system shrinks the window for
+the keyboard and therefore reports the keyboard's height to the app as
+zero -- nothing left to push up. The emulator here is a version where the
+old opt-out still works, which is why it pushed up in every test run and
+not on your phone.
+
+**This one is a reading, not a measurement** -- there is no Android 17
+device I can reach. So the other half of the change is making your phone
+able to answer it without a log. **Press `Diagnostics` with the keyboard
+open and screenshot the line beginning `insets:`.** It looks like
+
+    insets: dispatches=27 left=0 top=142 right=0 bottom=63 ime_bottom=0 ime_visible=false
+
+- `ime_bottom` in the hundreds, and the message box has risen: fixed.
+- `dispatches` counting up but `ime_bottom=0`: my reading was wrong and the
+  window is still being resized. That is the useful failure.
+- `dispatches=0`: the system is not telling the app about insets at all,
+  which is a third thing again and would say so in words instead of
+  numbers.
+
+The keyboard's height also arrives over a second path now (the animation
+callback), so the push-up follows the keyboard up rather than jumping when
+it lands.
+
+**"The resume glyph corruption is fixed."** Thank you -- closed on your
+evidence. That was the one nothing here could ever have confirmed: no
+emulator on this machine has a Vulkan adapter, and the software path may
+not destroy the surface at all, so the state you photographed was not
+reproducible here.
+
+Still not fixed, and still unrelated: the composer bar's grey background is
+not drawn on this build, so the transcript shows through behind the message
+field.
diff --git a/iris/build/outputs/apk/release/iris-bench-arm64.apk b/iris/build/outputs/apk/release/iris-bench-arm64.apk
index fa0ac32..abce3dd 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