Reduce event-history query work and bound cleanup batches

[ymichael]

Human comments

What was wrong

Several synchronous database paths read more event history or payload data than their results required: filtered high-water marks aggregated complete histories, open-turn recovery did not seek directly past interruption boundaries, request recovery repeated scans for requests from the same thread, and search loaded text before limiting matches. Destroyed-environment cleanup bounded rows but could rewrite megabytes in one batch. The timeline byte-budget helper also aggregated up to 2,001 payloads before potentially scanning them again.

What changed

Six separate fixes:

Issue	Fix	Before → after, ms
Latest sequence for seven active threads	Seek the final indexed event per requested thread	5.795 → 0.007
Open accepted turns	Seek past each requested thread’s latest interruption	1.467 → 0.216
Search for the	Rank and limit metadata before loading result text	87.482 → 80.570
Eight request IDs in one thread	Group request IDs so each thread history is scanned once per batch	21.932 → 2.926
Large-event environment detachment	Cap each batch at 256 KiB, preserving progress for oversized events and existing yields between batches	4.038 → 0.619 longest batch
Timeline byte-budget helper	Stop at the byte budget without a preceding aggregate scan	5.075 → 0.819 in the historical 512 KiB case

These are controlled warm benchmark medians from a private database snapshot or isolated fixtures, not deployed latency measurements. The original measurements preceded the removal of an experimental delta index; that index remains present in the benchmark snapshot. Detachment total work was 4.038 → 3.616 ms across 1 → 17 batches.

Rebased onto the snapshot-bound conversation-group pagination change in #3325. The byte-budget helper now serves only turn-summary detail expansion; main timeline pages no longer call it. A fresh comparison against main at the caller’s 4 MiB budget returned identical results in all six fixtures. An oversized 5,000-event window improved 2.667 → 1.717 ms, while a fitting 2,000-event window regressed 0.454 → 1.114 ms due to JavaScript iteration. Retained the early-stop behavior with this explicit tradeoff.

The net change has no checkpoint worker, schema/migration, server/daemon wire, CLI, or configuration changes.

How you verified

• Database regression coverage exercises lookup batching and query plans, byte-budget early exit, and byte-bounded environment cleanup, including an oversized first event.
• pnpm exec turbo run test typecheck --filter=@bb/db: 34 files, 481 tests passed; typecheck passed.
• pnpm exec turbo run test --filter=@bb/server -- test/services/threads/timeline test/services/threads/thread-runtime-display.test.ts test/services/database-maintenance-sweep.test.ts test/system/event-pruning.test.ts test/public/public-thread-data.test.ts test/public/public-thread-diagnostic-events.test.ts test/public/public-thread-timeline test/public/public-thread-search.test.ts: 20 files, 205 tests passed, including the new pagination and detail-expansion cases.
• pnpm exec turbo run build typecheck --filter=@bb/server: passed.
• git diff --check: passed. Rebase range comparison confirmed unchanged patches.
• Fresh timeline helper benchmark: migrated in-memory database, five warmups, 31 alternating measured iterations per implementation, exact result equality. Production was not modified or restarted; no deployed latency or full historical corpus replay is claimed.

AGENT GENERATED