perf(BSI): bound BatchEqual memory on scattered IN-lists with parallel scan fallback

[perfloop-agent]

Summary

On scattered IN-list queries the BSI BatchEqual match-trie degenerates toward a
near-complete binary tree and materializes a large number of intermediate bitmaps.
This adds a cheap branch-count estimate over the sorted query values; when the trie
would fan out past a crossover and the query has at least 128 values over a large
existence bitmap, BatchEqual skips the trie and computes the result with a linear
scan of the existence bitmap — GetValue for each existing column, kept when it is
present in the query set, partitioned across goroutines with the existing
ManyIterator/ParOr primitives. Contiguous and clustered queries stay on the trie
unchanged. The existence bitmap stays authoritative, so the result is always a subset
of it.

The fallback lives entirely in the BitSliceIndexing package; it adds no new exported
API to core roaring.

Benchmark

BenchmarkBatchEqualM128Scattered (allocation counts are deterministic / machine-independent):

metric	before	after
allocs/op	214,941	~23,900 (−88.9%)
B/op	~283 MB	~155 MB
ns/op	—	parity with the existing trie path (no regression)

Bounding allocations on scattered IN-lists is the goal; latency stays at parity with
the current trie path. Reproduce:

go test -run='^$' -bench='^BenchmarkBatchEqualM128Scattered$' -benchmem -count=10 ./BitSliceIndexing

Tests

go test ./... passes. Adds TestBatchEqualLargeQueryValues: a randomized BSI checked
against a GetValue ground truth across parallelism levels {0, 1, 2, 4}, exercising the
new scan path.

---

The full measurement trail — the benchmark, every candidate diff, and the verdict — is on
the public case page: https://app.perfloop.ai/t/oss/case_djnh9mjw8v

This is an automated contribution from Perfloop, opened for human review.

[lemire]

Merging.