v3: no hm+bf text domain — text_search requires the ORE term, capping eq+match string ingest at ORE speed (−87% vs v2) #355

Problem

The only v3 text domain carrying both equality (hm) and match (bf) capability is text_search, whose CHECK also requires the ORE term (ob). A v2 unique+match column migrating to v3 must therefore start generating ORE terms client-side, capping string ingest at ORE-generation speed:

Rows are also correspondingly wider. For comparison, other v3 ingest paths are at parity with v2 (int ORE ±2%; conversion + domain-CHECK overhead measured ≈ 0), so this is entirely the extra term.

Proposal

Add an hm+bf domain to the catalog (e.g. text_eq_match) for the common "exact lookup + pattern match, no ordering" column — or explicitly document the ORE cost as an accepted trade-off of the v3 type system. Note the catalog currently has no [Hm, Bloom] entry and from_v2 fails closed on a missing ob, so there is no workaround from the consumer side.

Evidence

report/V3_COMPARISON.md ingest table and results/ingest/v3/encrypt_string_v3_combined.json on cipherstash/benches#23 (numbers re-verified under cipherstash-client 0.38.1).