stack-encrypt: a typed equality query on text that cannot be normalized is refused only after the keyset is resolved — refuse it first, as the Go binding does #1321

Parent

#1279

What to build

Equality terms are derived from text normalized to Unicode 16 NFC. Text containing a code point that Unicode 16 leaves unassigned cannot be normalized, so it gets no term.

The two paths refuse it at different times:

• The binding (the Go SDK, via check_query) refuses it before any keyset is resolved.
• The typed chain does not. Its equality Supports impl refuses nothing, so the query fails only when the term is derived. By then the keyset has been resolved, which can cost a ZeroKMS round trip for a query that was never going to work.

Add the equality normalization check to the crate-private op::prepare module. Have the typed equality Supports::prepare and the binding's input check both call it. A bad equality query is then refused before any keyset on both paths, with the same error as today.

Acceptance criteria

• op::prepare has an equality function that refuses text the index cannot normalize, with the same TermError and diagnostic code the binding returns today.
• The typed equality Supports::prepare calls it; the binding's input check calls it in place of its own normalization check.
• The equality row in the table test from the first ticket is flipped from "known gap" to "both refuse before a key is loaded". Its load-counting assertion shows no key is loaded on the typed path.
• Interface tests on the equality function cover text that normalizes and text that does not.
• Term bytes are unchanged: query_operators.json and value_kinds.json pass as they are.
• cargo-mutants --in-diff leaves no surviving mutant in the changed code.

Blocked by

• stack-encrypt: replace Supports::check, verifier and admit with one prepare, called once per query #1318