Remove bitmapFactory.RemoveIds shrink paths — incompatible with docID reuse

Problem

roaringset.BitmapFactory exposes RemoveIds (and the Remove bitmap variant), used to shrink the prefilled negated-filter universe when objects are deleted. Once docIDs are reused (the integration/docid-reuse series), these shrink paths become actively wrong: calling RemoveIds on a deleted id after that id has been reused removes the NEW object from the universe, making it invisible to NotEqual/negated filters until restart.

The searcher-side lazy self-heal (inverted/searcher.go) that removes unresolvable ids from the shared prefilled bitmap has the same problem and needs to go with it — a lazily-removed reused id is likewise invisible to NOT filters.

Why removal is safe now

The shrink was only load-bearing for the filtered-aggregation meta count, which counted the raw allow list without resolving ids. #12890 changed that to count at resolution time (liveCount in aggregator/filtered.go), so deleted ids in the universe no longer overcount — the post-restart world (counter prefill includes all ever-allocated ids, nothing re-removes them at init) is already the behavior users observe, and it is correct.

RemoveIds also does not meaningfully save memory: the prefilled sroar bitmap uses fixed-size bitmap containers (no run containers), so punching holes does not shrink it.

Plan

Remove RemoveIds/Remove and the searcher self-heal together, scheduled with the free-list PR of the docid-reuse series (it is a precondition for enabling the reuse flag, and pointless churn before then).

Refs: #12890, #12886, integration/docid-reuse. Sibling deferred-bug issues: #12891, #12892.