Keep older timeline pages loaded while a thread streams

[SawyerHood]

Human comments

What was wrong

Since #3325, mergeLoadedTimelineWithLatest replaces every loaded row whenever the latest page's historySnapshot changes, and the snapshot includes maxSeq, so each appended event unloads all older pages. When the previous conversation group is larger than the 1,500-event latest-page budget, it exists only on an older page. While a thread streams, each event removes it, the "Loading older messages" sentinel scrolls back into view, auto-load fetches it again, and the next event removes it again. The controller also discarded an older page still in flight whenever the snapshot moved. Separately, a page's older cursor used the group's first displayed row. Rows recorded after a request but displayed above its message, such as "Provider environment resolved", formed their own group with a higher sequence, so the first older request re-served the current group and merging it moved that row below the reply.

What changed

• packages/client-core mergeLoadedTimelineWithLatest: when a new latest snapshot reaches the loaded tip, loaded older pages stay and only the rows the latest page covers are replaced. It still rebuilds from the latest page when the pages do not line up, when they share no rows and leave a gap, or when the server reports a later change to a row the page omitted. On a cursor tie it keeps the walk's cursor. prependOlderTimelineRows keeps the loaded order when an older page repeats loaded rows.
• useThreadTimelineController: an in-flight older page is applied when its request cursor is still the loaded olderCursor, instead of requiring an unchanged snapshot.
• apps/server pagination: new timelinePage.olderRowsSourceSeqEnd, the greatest sourceSeqEnd among rows the snapshot projected before the page's returned rows but omitted (null when none). That covers older conversation groups, owned groups a size cut left out, and the leaves a content cut dropped from the page's oldest group, so a command that completes before a content cut still triggers a rebuild. A row that keeps changing before a content cut therefore rebuilds on each refresh. Leading rows recorded after a group's message now join that group, and its cursor is the message row.
• packages/server-contract: the field is optional in timelinePageMetadataSchema, matching the other snapshot fields. No daemon wire change, so HOST_DAEMON_PROTOCOL_VERSION is unchanged.
• docs/timeline-pagination.md describes the new rule. This relaxes Fix timeline pagination with snapshot-bound conversation groups #3325's "a new latest snapshot replaces loaded rows" behavior for refreshes that only append to newer rows; a later change to a row the page omitted still replaces them.
• One Fix timeline pagination with snapshot-bound conversation groups #3325 assertion changed in timeline-event-budget.test.ts. After a late append that sorts into the newest group, the merge must now equal the full canonical timeline rather than the latest page alone.

How you verified

• New client-core merge tests: a streaming refresh keeps older pages, a tie keeps the walk cursor, a content-cut running turn keeps its head, a group starting right after the tip appends, no overlap with a gap rebuilds, a change to an omitted row rebuilds, and a repeated group keeps the loaded order. 5 of these fail against main's merge code.
• New controller test: an in-flight older page applies across refreshes that advance the snapshot, and older rows survive later refreshes.
• New server unit tests: the cursor anchors at the message row, and the rebuild value covers context-only older groups, owned groups a size cut left out, and rows before a content cut.
• Endpoint tests: walked history stays equal to the canonical timeline after an append to the newest group. A late command completion reports a rebuild both in an older group and before a content cut in the newest group; after the rebuild and reloading older pages, the rows equal the canonical timeline. The content-cut case fails with the previous pagination code.
• pnpm exec turbo run typecheck for @bb/server-contract, @bb/client-core, @bb/server and @bb/app, and earlier for @bb/cli and @bb/mobile.
• pnpm exec turbo run test for @bb/client-core, @bb/server-contract, @bb/cli, and @bb/server -- test/services/threads test/provider-corpus test/routes. The provider corpus correctness walk skipped because no corpus was available.
• App Vitest run directly for src/components/thread/timeline, src/views/thread-detail and src/hooks/queries, because the PWA icon check fails in this checkout.
• Browser, isolated source instance with BB_FF_TIMELINE_WINDOW_EVENT_BUDGET=20 and real Claude Code turns sent from the composer. A MutationObserver recorded whether the previous assistant message stayed in the DOM while a follow-up streamed. With main's client merge it left and returned 8 times within about 4 seconds, and "Loading older messages" showed in 19 samples. With this change it never left over a 30-second turn.
• Replayed a real affected thread's events through the server at each of 49 consecutive sequences, feeding both clients. With main's client the previous message dropped on 49 of 49 refreshes; with this change, 0. The rebuild value stayed null throughout.
• The browser check ran before rebasing onto Speed up thread rendering while content streams #3591, and the replay before the omitted-rows change. Tests and typechecks were rerun after both.

🤖 Generated with Claude Code

AGENT GENERATED