Reuse unchanged large thread timelines

[brsbl]

Human comments

What was wrong

Unchanged timelines over 200 rows rebuilt on every fetch because they bypassed the response cache. The delta cache already retained their rows, but could not serve a complete response. A 730-row synthetic thread repeatedly took 35.9–39.5 ms locally.

What changed

Repeated requests reuse the latest complete response for the same event revision and display parameters. New revisions rebuild, and history rewrites invalidate retained responses. The existing delta cache owns the response, preserving its key and revision limits.

How you verified

• The real SQLite HTTP regression failed on the original repeated build in remote CI.
• Same fixture before/after: median API TTFB 36.4 → 8.9 ms (76% lower); all response fields matched by SHA256. Small-thread responses also matched.
• Exact final head b383db14b: appended complete turn updated 730 → 732 rows and revision 3112 → 3117; context clear returned one row at revision 3118 with old content absent. Repeated full responses matched in both states. Same-revision provider rewind was not exercised in the dev app.
• Final long-thread browser opens completed with zero console errors in Chrome for Testing 153.0.8010.52. Host contention makes these timings unsuitable for an overall UI speedup claim.
• Final remote CI: all test suites, build, typecheck, lint, macOS packaging, and Node compatibility checks passed. Linux packaging is blocked by a timeout downloading libfuse2t64 from mirrors.edge.kernel.org; repeated attempts failed at that external dependency. The PR remains draft.

BB-Thread-ID: thr_ibbvwvkba7

AGENT GENERATED