fix(messages): release Virtua's held range when scrolling stops - #2032

Summary

• While you scroll the channel timeline, the list renders extra rows ahead of where you are heading, so a fast scroll doesn't show blank space. Once scrolling stops, it renders that extra on both sides.
• Rows above the viewport sometimes change height, for example as older history measures in. The list then corrects the scroll position so the rows you are reading stay put. The list holds its rendered rows in place until that correction's own scroll event arrives.
• Some corrections never get a scroll event of their own: the correction moved nothing, or another write undid it in the same task. Before this change, the held rows then stayed in place even after scrolling stopped. The timeline sat idle with extra rows on one side only, and a row just past the viewport on the other side stayed unmounted until the next scroll.
• That broke main CI in Linux WebKit: history-loading.spec.mjs "a held pointer keeps its place after the page's reader row unmounts" (run https://github.com/block/buzz-app/actions/runs/41120162311). After a 91px correction, the list went idle with no rows rendered below the viewport. The held message row did not remount before the test failed.
• Now, when scrolling stops, the list releases held rows and re-renders. So once idle it again renders extra rows on both sides, as patches/README.md describes.

Details

• The change is in our Virtua patch (patches/[email protected]; Virtua is the list virtualization library):
  • The store's scroll-end step now clears a pending correction and re-renders, even when the scroll direction was already idle.
  • Before that, the driver's scroll-end reads the native scroll offset, as its viewport-resize path already does. A correction whose scroll event arrives after the 150 ms scroll-end timer is then handled as its own event. Without this, the release would re-render from the pre-correction offset: a 40-row history page would mount rows 0–24 while the viewport sat at 2300–2800px.
• What the CI trace shows, and what it doesn't: it shows the list idle with extra rows on one side only, right after the correction. It does not show which write left the correction without a scroll event.
• Known limit, stated in the README: a correction made after scrolling has already stopped, with no later scroll event, still holds its rows until the next scroll. This is unchanged from before.
• Tests (src/features/messages/virtua-compensation.test.mjs) run the installed, patched store and driver:
  • A correction undone before its scroll event, then the driver's real scroll-end timer: the list renders both sides once idle.
  • A held range with the direction already idle: scroll-end re-renders.
  • Scroll-end fires before a history page's correction scroll event: the held rows stay correct.
  • The first two fail on main's patch. The third fails without the driver change. All 43 pass with both changes.
• Browser cases added or removed: none. The browser journey that failed in CI is unchanged.
• Validation, local macOS: typecheck, all src/features/messages Vitest tests, and the history-loading, image-scroll and initial-position browser files in Chromium and WebKit (2 workers).
  • One WebKit case, "input after the page lands starts from the reader's row", failed intermittently by about 40px: 2 of 31 runs with this change, 2 of 20 with main's patch. It is an existing local flake, not caused by this change.
  • The CI failure itself did not reproduce on macOS, so hosted Linux WebKit is the real check.

🤖 Generated with Claude Code