EQL v3 Drizzle: encrypt all query operands with encryptQuery (not client.encrypt)

[coderdan]

Context

The EQL v3 Drizzle adapter (packages/stack/src/eql/v3/drizzle/operators.ts) encrypts scalar query operands (eq/ne/gt/gte/lt/lte/between/notBetween, and bloom contains) with client.encrypt, which produces a full storage envelope including the ciphertext c, cast ::jsonb. JSON containment (added in #621) is the first and only operator using client.encryptQuery, which produces a query term (hm/op, no ciphertext).

Problem

A WHERE-clause operand should be a query term, not a storage envelope:

• Sending the ciphertext c for a query value is wasteful (larger payloads) and semantically wrong — it's a query, not a value to store.
• The asymmetry forced encryptQuery to be declared optional on the operand-client type, with a runtime guard (OperandEncryptionClient.encryptQuery?) that only the JSON path exercises. Reviewers found this confusing (see feat(stack): EQL v3 JSON support — types.Json + containment #621 review).

Proposed change

Migrate every v3 Drizzle operator to client.encryptQuery (with the appropriate queryType/returnType), so:

• all operands are query terms with no ciphertext,
• encryptQuery becomes a required capability on the operand client, and the optional guard/branch is removed,
• unit tests for each operator update to assert query-term operands.

Notes

• This predates feat(stack): EQL v3 JSON support — types.Json + containment #621 (the encrypt-for-scalars decision came in with the v3 adapter). feat(stack): EQL v3 JSON support — types.Json + containment #621 deliberately left it alone to stay JSON-scoped.
• Verify eql_v3.eq/neq/comparison functions accept the narrowed query term as they do the full envelope, against the live integration matrix.

https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w

[coderdan]

Resolved by #636 (v3 Drizzle operands encrypted via encryptQuery), merged into the 1.0 candidate #535.