events: match queries one slab at a time

[tamirms]

What

Rewrites how the events store matches a getEvents query. It now walks the query's window one slab at a time (65,536 consecutive event ids, roaring's container size) instead of combining whole-chunk bitmaps before the first fetch.

Tests: TestMatches_FetchesOnlyTrueCandidates requires the fetched ids to be exactly the query's matches; the matrices in slab_match_test.go compare against an oracle computed without the index; TestSlabStepperSkipsCandidateFreeSlabs pins which slabs the walk opens; roaring_contract_test.go pins, against roaring alone and under -race, the properties the shared index bitmaps rely on; TestMatches_ConcurrentIngestBorrowSafety holds index snapshots across a walk while ingest keeps writing.

Why

A query is a list of filters, each an AND of terms (contract id, topics, event type), and the candidates are the ids that satisfy any filter inside the window. Today the engine intersects each filter's term bitmaps across the whole chunk, unions the results, and only then restricts to the window, all before the first event is fetched. Its cost tracks the terms' size across the chunk rather than the window or the page: a page of 1,000 events from a popular contract with a topic constraint first intersects that contract's millions of ids.

This PR turns each filter into plans, each a plain AND of terms (a topic-count range becomes one plan per count), and walks the window slab by slab in the requested direction. On each slab, every plan is one FastAnd over the slab's ids in the window and the plan's terms, and the plans' results are ORed and handed to the fetch. Before opening a slab, the walk asks each term for its next id (NextValue / PreviousValue) and jumps to the first slab that can hold a candidate, so a rare term opens only the slabs where it has events. Work scales with the window and the page, memory per query with one container, and both directions share one path. The first batch is the caller's page size, so a full page arrives in one fetch.

Known limitations

• At roaring v2.26.0, a plan that matches nothing on a slab still allocates one intermediate there. runcontainer: count or test before allocating in run-bitmap intersections RoaringBitmap/roaring#566 and fastaggregation: count before allocating in FastAnd RoaringBitmap/roaring#572 remove that; bumping to a release with them is a follow-up.
• Not benchmarked on its own. rpcv2: getEvents read-path performance across both tiers #968's end-to-end numbers (hot p50 7.41 → 3.68 ms, cold 18.3 → 4.3 ms at sac density) include this engine together with the block-size, fetch and fan-out changes, which follow as separate PRs.

🤖 Generated with Claude Code