fix(web): chat stays pinned when the terminal drawer opens during a turn#32826

Problem

With the chat following its end while an agent turn is running, opening the terminal drawer pushes the newest content below the visible area. It slides back only after the drawer stops moving. Idle, or with reduced motion on, the end stays pinned.

While a turn runs, MessagesTimeline passes an animated maintainScrollAtEnd so streamed text scrolls smoothly. Legend List (3.7.2) has one animated flag for every trigger, so a viewport resize also gets a smooth pin, queued behind any smooth pin already running.

Change

MessagesTimeline handles LegendList's onLayout, which Legend calls right after it has measured the new viewport. When the viewport height changes, the timeline is on the working (smooth) follow config, and the list is following its end, it calls scrollToEnd({ animated: false }). That pre-empts a running smooth pin and keeps follow on. scrollToEnd commits through a React update, so the call is wrapped in flushSync to land before the resized frame paints.

• Content growth (streamed text, item and footer layout) still scrolls smoothly.
• Width-only changes, idle, reduced motion, Find, citations, position restore, anchored turns and fullscreen apps take the existing paths unchanged.
• A reader who has scrolled away is not pulled back: Legend clears isFollowingEnd on the first scroll away.

No dependency patch. The earlier version of this PR patched @legendapp/list@3.3.5; main has since moved to 3.7.2 and dropped that patch, so the fix now lives in the app.

Scope and approval

Fixes pingdotgg/t3code#32778

The issue was triaged as a bug through the automated issue flow. Web and desktop share this component; the native mobile app uses its own feed and is unaffected.

Verification

• MessagesTimeline.browser.test.tsx gains "pins the live end at once when the viewport shrinks during a turn": a smooth pin is running, the viewport shrinks by more than the new viewport, and the next pin must be instant with the end in view; further streamed content pins smoothly again; after the reader scrolls to the top, a resize scrolls nothing. The case subscribes to the shared resize observer before the list mounts, as the app shell does. It fails on main (the last scroll is smooth). MessagesTimeline.browser.test.tsx and timelineViewport.browser.test.tsx pass (56 tests on the head). vp run check:changed passes.
• The test runtime commits React updates before paint either way, so first-paint timing is proven by the recordings below, not by the test.

Evidence: real web app, Chromium 148 headless shell driven by Playwright/CDP, no device emulation, DPR 1, 1280×800 dark unless stated, panel animation 200 ms, client clock frozen. Before is main feb9c6b842, after is c6b46f306c; the head 72eabe08cd only merges main, whose one timeline change is the minimap's at-end state. Each side ran its own dev server on a fresh database with synthetic turns from the Replay provider. Distances are from the end of the timeline scroll container, read in a ResizeObserver that runs after Legend's, which is the position each frame paints with. Transient stills are phase-matched at equal timeline height.

R01: first changed paint at equal timeline height (before, after, Diff0, DiffT).

R01 phase-matched: before, after, Diff0, DiffT

Recordings: R01-before.mp4 · R01-after.mp4

R02: reopening the drawer while markdown streams.

R02 phase-matched: before, after, Diff0, DiffT

Recordings: R02-before.mp4 · R02-after.mp4 · R07: before · after · R09 recovery: before · after

Settled stills are identical at threshold 0 except for 8 composer-edge pixels, which also differ between two runs of the same build. Every row, with its Before | After | Diff0 | DiffT table, narrated steps, recordings and full ResizeObserver series: Evidence.md. Matrix: fixture-matrix.md. Seed, drivers and sampler: scripts · reproduction notes.

What else differs between the sides, outside this change: streaming phase, server elapsed-time labels, caret and hover timing. In the R01 and R02 mid-slide stills, 6 pixels at the ends of the terminal toolbar's divider lines differ (delta 16/255): the frames match at whole-pixel timeline height, but the drawer sits at a slightly different sub-pixel position.

Not verified:

• A resize that coincides with an item remeasurement while markdown streams can still paint one frame short of the end (R02, 191 px, pinned on the next captured paint).
• Pressing the end button while markdown streams and then resizing can slip by up to 93 px for two samples before pinning (R09).
• While the drawer stays still, streamed growth follows smoothly and can briefly trail the end, as on main.
• Windows desktop, the reporter's platform. The desktop app renders this same web code; no Electron capture was made.
• Width-only resizes (R08), position restore, anchored turns, citations, fullscreen apps and the empty list skip the new call. R08 was captured on c6bff8b1dd; the rest were not captured.

AI-assisted; verified with the tests and tools listed above.