fix(tui): keep the reader's place while scrolled up in a long session - #53219

Note: I'm aware v1 is now the maintenance branch and new features go to v2 only. This fix is here for others who want it on v1. I will submit a v2 version once I've migrated my plugin setup to v2.

Issue for this PR

Closes #41243 (root cause analysis of #29094 / #4196). The earlier fix for it, #41247, was closed by the automated PR cleanup without a review.

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The sync store keeps at most 100 messages per session and drops the oldest one on every new message (context/sync.tsx). Each drop removes rows above the viewport while scrollTop stays fixed, so a reader scrolled up in a long session sees the text slide up with every new assistant message. Once it reaches the bottom, sticky scroll re-engages and follows the stream again. Short sessions never hit the cap. That is why the scrollbox looks correct in isolation: sticky scroll itself is fine, as #41243 found.

keepScrollAnchor() (in util/scroll.ts) listens to the root's layout-changed event. That event fires after the new layout is computed and before any renderable reads it. When the scrollbox is not at the bottom, it takes the first child that was visible under the old layout and scrolls by the distance that child moved, so the frame is drawn with the view in place. At the bottom it does nothing, and following the stream is unchanged.

Compared with #41247, this measures the layout change itself instead of predicting the pruned height from the message list. It needs no id wrapper on assistant messages, and it covers any other height change above the viewport too.

How did you verify your code works?

• New packages/tui/test/util/scroll.test.tsx renders a sticky-bottom scrollbox and rotates items the way the transcript does. Scrolled up, the first visible line stays put (item 25). Without the fix it drifts to item 28 after three rotations. At the bottom, new items are still followed. bun typecheck passes, and the TUI suite passes apart from DiffViewerFileTree > does not render text markers for highlighted rows, which is flaky under full-suite load and passes alone.
• Drove a real TUI in tmux (isolated XDG dirs) against a local fake OpenAI-compatible server. The server streams markdown, reasoning and a bash tool call per step, so the session grows past 100 messages. I sampled the first and last visible step markers once per second after scrolling up five wheel notches:

Before (dev), the view slides down the transcript:

13:33:08  Step 96 prose      Step 96 closing
13:33:12  Step 98 findings   step98(
13:33:17  Step 99 findings   step99(
13:33:21  Step 100 findings  step100(
13:33:25  Step 101 findings  step101(

After, the view holds for 40s while the stream keeps going, and End resumes following:

14:45:53  Step 586 closing  Step 587 bullet two
14:46:10  Step 586 closing  Step 587 bullet two
14:46:30  Step 586 closing  Step 587 bullet two
--- End
14:46:36  Step 595 closing  Step 595 closing
14:46:39  Step 596 findings step596(

In sessions under 100 messages, scrolled-up reading already holds on dev for wheel, PageUp and line-up. This change leaves that path alone.

Screenshots / recordings

Text frames above (tmux capture-pane).

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

This PR is AI generated, but under direct supervision and on request of @Nowaker.