Bound timeline cache revisions per request shape

[amadad]

Summary

• Retain at most one built timeline response revision per request shape.
• Replace obsolete streaming revisions even when the new response exceeds the cache row cap.
• Preserve the previous cached revision when a replacement build throws.
• Keep the existing LRU bound across independent request shapes and leave row-delta state in its separate cache.

Why

The response cache was keyed by maxSeq, so every appended event could add a new entry. The intended safeguard skips responses above 200 projected rows. It does not cover many real active windows. Observed streaming windows projected only 28–74 rows while reading hundreds of events. One request shape could therefore consume all 128 LRU slots with unreachable revisions.

The cache now owns both identities. The request shape selects the slot. maxSeq selects the revision stored in that slot. Callers no longer encode this retention policy in an opaque string key.

Regression proof

Before the fix, 128 successive maxSeq values for one request shape produced cache.size === 128. The regression now asserts cache.size === 1. Tests also cover:

• cacheable to over-row-cap replacement
• failed replacement builds
• independent request shapes
• revision replacement preserving LRU order
• the unchanged public timeline row-delta route

Validation

• pnpm exec turbo run test --filter=@bb/server --force -- --run test/services/threads/timeline-cache.test.ts test/public/public-thread-timeline-delta.test.ts — 14 passed
• umask 0022 && pnpm exec turbo run test --filter=@bb/server --force — 1,319 passed
• pnpm exec turbo run typecheck --filter=@bb/server --force — passed
• pnpm exec turbo run lint --filter=@bb/server --force — no server lint task configured
• Prettier and git diff --check — passed
• Independent diff review — no findings

No API, database, or server/daemon wire contract changes.