stack-encrypt refactor: complete configured definitions and typed query APIs #1486

Writes and queries must use the same validated target definition; the Rust facade must expose the operations already available through dynamic bindings.

Acceptance:

• Resolve typed Rust options factories and dynamic options through the same target-owned validator before key I/O.
• Specify immutable fixed definitions versus runtime instances, initialization/retry behavior, generic identity, lifetimes and normalized-options reuse.
• Provide typed field handles and coherent definition selection for encrypt/decrypt/query operations, including runtime-authored queries with explicit validation.
• Reuse stack-encrypt: element match and jsonpath match have no typed Rust API — only the binding layer, with no compile-time checks #1459 for typed JSON element/predicate APIs and stack-encrypt: a query's refusals are written separately for Rust callers and the Go binding, and have drifted once — give both one query preparation #1279/stack-encrypt: replace Supports::check, verifier and admit with one prepare, called once per query #1318–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 for shared query preparation/refusals.
• Replace EQL serialization round trips with direct typed conversion where still present; preserve catalog/guest/SQL agreement.
• Keep custom unregistered Rust stages explicitly nonportable and test capability refusals.
• Execute static/generated/dynamic examples and relevant conformance cases.

Coordinate #1483, #1476 and #1475. Do not reimplement the already-landed Go configured JSON target support or silently rename its shipped APIs.

Plan: conformance roadmap and API redesign #1365.