Investigate intermittent paused-frame live-follow browser regression

The browser suite intermittently fails remote messages keep a live channel pinned without unread UI in tests/e2e/chat.spec.ts. The failure is the absence of paused live message 4 at line 2239 after the preceding paused-frame message was visible.

Observed on PR #204 at 1ba373e7990efa58a2ec7bef4169556beb299f4c: first CI attempt passed 256 tests and failed this one. The full browser job passed on the unchanged second attempt. No timeout, assertion, or retry-policy changes were made to obtain that result.

The test reaches the live edge, appends a large message from another user, pauses new animation-frame callbacks, and then appends two further messages separately. Each must reach the DOM before the next is sent, so one fetch containing both cannot mask blocked ingestion.

Local evidence so far:

• The same scenario passed five runs with the fixture CLI invoking the already-built server binary. This avoided a local go run filesystem stall before the browser scenario; it did not change the browser assertions.
• Twelve instrumented baseline append pairs passed normally, and twelve passed with 6× CPU throttling. Native resize/scroll traces showed recalculated bottom positions before the following scroll callbacks in those runs.
• The scroll component and affected event-ingestion path were unchanged by the password feature. No authentication failure was observed in this test.
• Virtua 0.50.6 reports both user and programmatic movement through onscroll(offset), and its imperative target follows resize measurements for a short interval. That is relevant context, but does not establish the cause of this CI failure.

The missing-message root cause remains unknown. Preserve the failing browser's DOM/error context, WebSocket event order, message fetches, and native scroll/resize ordering on a recurrence. Distinguish an event not being fetched from a fetched message being virtualized out of the DOM or a follow-state transition.

A separate investigation reproduced an unfinished follow-to-bottom command overriding a real upward wheel scroll after frames resume. That adjacent command-lifetime defect should be repaired with its own before/after proof; it is not yet evidence that the missing-message failure above has the same cause.

Start with the remote messages keep a live channel pinned without unread UI test in tests/e2e/chat.spec.ts around line 2239, using the fixture CLI and already-built server binary. On a recurrence, preserve the browser DOM and error context, WebSocket event order, message fetches, and native scroll/resize ordering. Done means identifying whether the message was not fetched, was virtualized out of the DOM, or was blocked by a follow-state transition, with before/after browser evidence.