iris bench: the fling curve was a straight line, and the keyboard was a targetSdk

ai-app-2 rustify 4274b8b. Iris's 2026-09-07 phone report on the previous
build: the resume glyph corruption is fixed (closed on her evidence), the
fling "seems to just be linear velocity with an abrupt stop", and the
keyboard still does not push anything up.

The fling was arithmetically linear: two halves of AOSP's spline build loop
were transposed, which made its two tables identical, and the lookup that
reads one against the other then reduces to the identity. Ported exactly
now from OverScroller.java and Compose's SplineBasedDecay.kt. The keyboard
was `targetSdk = 34` in the bench app's build.gradle against the Compose
app's 37; below 35 the window is resized for the IME and the reported ime
inset is therefore zero. Now 37, plus a WindowInsetsAnimation.Callback, and
the Diagnostics pane prints the insets and how many times the platform has
delivered any -- which is what her screenshot will settle, since the
targetSdk reading could not be measured on any device here.

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

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.