Stop the composer sticking above the bottom of the screen after the keyboard closes

Reported: closing the keyboard on purpose, while a reply was streaming,
left the composer floating above the bottom of the screen for the rest of
the session -- a bar of background colour under it, nothing that closed it.

The composer's position and the transcript's bottom padding are both driven
by the raw, animated `WindowInsets.ime` value, read inside a `graphicsLayer`
block specifically so a keyboard frame invalidates layer properties only
rather than recomposing the whole screen (see the layout note above it).
That value is carried by a `WindowInsetsAnimationCallback`, and a callback
interrupted mid-flight leaves whatever it was carrying frozen at its last
value with nothing left to correct it -- no further keyboard movement is
coming to fire the callback again. A streaming reply invalidates the view
every frame, which is exactly the condition known to starve a running
callback of its `onEnd`, and that is the "actively responding sessions"
correlate in the report.

`WindowInsets.isImeVisible` doesn't share that failure mode: it is set once,
from the platform's own start/end of the transition, over a different path
(`onApplyWindowInsets` rather than the animation callback) -- so it cannot
get stuck mid-animation the way the interpolated value can. Read once per
keyboard toggle and used to force both the composer's translation and the
transcript's reserved padding back to exactly zero the moment the platform
says the keyboard is gone, whatever the animated value still claims.

Checked on the emulator with an actively streaming echo session: opened the
keyboard, closed it with the system back gesture while the reply kept
growing, and the composer settled flush at the bottom with the transcript
filling the freed space, both immediately and after the keyboard was
reopened and closed again.

AGENTS.md

@@ -599,6 +599,23 @@ machine belongs in `~/.claude/TOOLCHAIN.md` (toolchain versions) or
   logged" failures). Keep every exercise of a logging code path under the
   one capturing subscriber — that's why the auth middleware has a single
   combined gating+logging test.
+- **The composer can get stuck floating above the bottom of the screen after
+  the keyboard closes, while a reply is streaming.** The composer's position
+  and the transcript's bottom padding are both driven by the raw, animated
+  `WindowInsets.ime` value read inside a `graphicsLayer` block, to avoid
+  recomposing the whole screen every frame of the keyboard's animation (see
+  the layout note above it). That animation is carried by a
+  `WindowInsetsAnimationCallback`, and a callback interrupted mid-flight
+  leaves whatever it was carrying frozen at its last value with nothing
+  left to correct it, since no further keyboard movement will fire it
+  again. A streaming reply invalidates the view every frame, which is
+  exactly the condition known to starve that callback of its `onEnd`.
+  `WindowInsets.isImeVisible` (`ExperimentalLayoutApi`) does not share the
+  failure mode -- it is set once, from the platform's own start/end of the
+  transition over a different path -- so it is read once per keyboard
+  toggle and used to force both places back to zero the moment the
+  platform says the keyboard is gone, whatever the animated value still
+  claims.
 - **The keyboard pans the window unless the activity opts into resize.**
   Without `android:windowSoftInputMode="adjustResize"`, opening the IME
   slides the whole window up (top bar off screen) instead of resizing —