Preserve semantic timeline groups across window boundaries

[ymichael]

Human comments

What was wrong

Timeline transport windows were projected independently even though projection groups by semantic turns, messages, and item lifecycles. Event-count and byte cuts could therefore split one item or completed-turn group across pages. Each page then made a locally plausible but globally different decision: duplicate “Worked for…” rows, missing or extra assistant messages, incorrect user-message turn assignment, double-counted items, or a row stuck pending. Client-side coalescing by turn-row id could join some work fragments, but it could not reconstruct the semantic context discarded at the server boundary and could merge across real conversation boundaries.

What changed

This stacked PR makes the timeline server own semantic window closure. A bounded page now carries only the lifecycle, accepted-input, assistant-boundary, compaction, background-task, and delegation context needed to project its selected events as the corresponding slice of the unwindowed timeline. Whole items belong to exactly one window, completed-turn fragments use page-local identities, and the client coalesces only adjacent fragments at the actual page seam. Detail hydration uses the same ownership rules, so expanding a coalesced row does not reintroduce duplicate or half-finished items.

The query path avoids global item-span work for lifecycle pairs already proven to be contained and limits future-assistant lookups to turns crossing the byte boundary. A nested-delegation-only byte slice has a narrow fallback when it has nonzero summarized work but no root message from which to derive bounds.

This depends on #2464. There is no server/daemon wire change, so HOST_DAEMON_PROTOCOL_VERSION is unchanged.

I also tested the smaller client-boundary-only alternative against the copied production corpus. It matched the canonical unwindowed projection on only 103 of 118 cap-affected threads; the remaining failures included every error class above. That is why the server closure logic is retained despite the larger diff.

How you verified

• Added/updated regression coverage for event and byte cuts, straddling item lifecycles, accepted input and human boundaries, assistant messages, nested delegation, context compaction, provider input, and client page-seam merging. The existing large-delegation integration test caught an empty newest-page regression during the final full-suite run; the added zero-root-message fallback makes it pass.
• Full server suite: 2,059 passed. App: 3,410 passed (4 skipped). Mobile: 888 passed. Database: 410 passed. Thread view: 374 passed. Client core: 245 passed.
• Turbo typechecks passed for app, mobile, server, client-core, database, and thread-view.
• Copied-production audit (784 threads, 888,665 events): all 118/118 event- or byte-cap-affected threads exactly matched the canonical unwindowed conversation/turn projection across 457 timeline pages. All 13/13 segment-limit stress threads matched, and 1,029 expandable groups (including all six paginated detail ranges) completed with zero failures or warnings.
• Alternating copied-production benchmark: affected-thread initial load was neutral (2.92 ms median before and after). Walking every historical page was slower: 43.6 ms median on main versus 54.5 ms here, or about 11.5 ms per affected thread; the largest thread was +399 ms across 30 pages. This is an explicit correctness tradeoff on older-page loading, not hidden initial-load cost.

AGENT GENERATED