Produce EQL v4 TextMatch from Stack Encrypt's match terms #1181

Part of #1131, which keeps TextOrd, TextOrdOpe and TextSearch.

Problem

stashgen refuses TextMatch, so a Go field can't use encrypted substring search (@@). The engine already derives Bloom-filter match terms. What's missing is the EQL v4 type built from them, and a check that EQL's SQL can compare them.

Proposal

• Write the engine's match-term positions as EQL's smallint[] Bloom filter. Pin eql-bindings' own match configuration (3-grams, lower-cased, k = 6, 2048 bits) so that stored filters and new queries can't drift apart.
• Add ("text", "match") to ENCRYPTION_DOMAINS, so TextMatch and TextMatchQuery are producible and stashgen accepts encrypt_into=TextMatch.
• Prove @@ in PostgreSQL against an eql_v4 install: a shared substring returns every row, a unique one returns one row and a miss returns none. A bound parameter uses the GIN index on eql_v4.match_term(col).
• Document the limits: false positives, stored @@ query only until query @@ stored on an EQL match column returns no rows: the reversed @@ overload tests containment backwards #1171 is fixed, and text shorter than three characters is refused when stored or queried (lifting that is tracked in Tracking: implement ADR-0009, operator-typed query terms for Stack Encrypt #1178).