EQL v3 Supabase: JSON containment/selector operands carry full storage ciphertext in GET query strings

[coderdan]

Follow-up to #650/#653. The v3 Supabase adapter's encrypted-JSON operands (contains(), selectorEq/selectorNe) are FULL storage envelopes: a root decryptable ciphertext c plus one ciphertext-bearing sv entry per node of the needle document — the exposure scales with sub-document size, and PostgREST filters travel in GET query strings (URL logs, proxies, Supabase request logs).

This is strictly more exposure than the same operation on Drizzle, whose containment needle is ciphertext-free (encryptQuery → eql_v3.query_jsonb). The Supabase adapter can't reach that overload because PostgREST casts filter operands to the column's own domain (eql_v3_json), whose CHECK demands the storage document shape.

Closing the gap needs one of:

1. An EQL-bundle change: accept a ciphertext-free needle THROUGH the storage-domain cast (e.g. relax the eql_v3_json entry CHECK for query-shaped values, or a dedicated needle form the (json, json) overload normalizes via to_ste_vec_query) — coordinate with EQL v3: ordering-at-selector needs a (eql_v3_json, eql_v3_json) comparison overload for PostgREST encrypt-query-language#407, which needs a needle convention for ordering anyway.
2. PostgREST operand casting (upstream), which would unblock eql_v3.query_jsonb directly — the same wall every scalar v3 filter hits (tracked in the adapter's class doc).

Until then the skill documents the scaling exposure explicitly (see skills/stash-supabase, "Encrypted JSON querying"). Related: cipherstash/protectjs-ffi#137 (ordering needles), cipherstash/encrypt-query-language#407 (PostgREST ordering overload).

https://claude.ai/code/session_01MxTTPaPP16m6br7Hoab94w