Paginate oversized timeline turn details

[ymichael]

Human comments

What was wrong

Completed-turn detail hydration used one exact sequence-range response with a 4 MiB stored-event safety limit. After full output and preview-output reads both exceeded that limit, the route returned 413 timeline_window_too_large, so expanding an otherwise valid “Worked for…” row failed. The first pagination implementation also keyed pages only by turn and expanded the entire completed turn, which crossed visible assistant-message boundaries instead of preserving the exact rendered row.

What changed

Added a forward-paginated turn-detail resource. Its first request still uses the existing exact-range path unchanged; only the former 413 case falls back to bounded pages. The requested sourceSeqStart/sourceSeqEnd now flow through the web app, mobile app, server contract, SDK, route, and cache keys, and continuation cursors are bound to the thread, turn, and exact row range. Clients fetch one page initially, merge page boundaries by stable row identity, and expose “Load more work” for continuation pages.

The existing exact-range resource remains available and unchanged. There is no server/daemon wire change, so HOST_DAEMON_PROTOCOL_VERSION is unchanged. The plugin SDK version is bumped to 0.4.23 for the added public thread-detail API.

How you verified

• Added a red-before/green-after server regression proving two ranges in the same turn hydrate to disjoint command sets, plus cursor/range binding coverage.
• Server route/service tests: 109 passed.
• Web query tests: 20 passed; mobile timeline tests: 7 passed.
• Client core: 244 passed; thread view: 372 passed; database: 410 passed.
• Server contract: 60 passed; SDK: 96 passed; plugin SDK: 219 passed.
• Turbo typechecks passed for app, mobile, server, client-core, db, sdk, server-contract, thread-view, and plugin-sdk.
• Production-copy compatibility audit: 77 exact ranges were byte-for-byte identical to the legacy resource; 10 former 413 ranges completed in 2–3 forward pages; zero new failures. Exact-range median was 33 ms legacy vs 28 ms new. Formerly failing ranges returned a first page in 135 ms median and all pages in 174 ms median.

AGENT GENERATED