EQL v2 removal: review remediation for #772

[tobyhede]

Review-remediation tracker for #772 (remove-v2).

Current state

The original detailed audit was an in-flight branch snapshot and is preserved in this issue's edit history. The removal work it tracked is now integrated on remove-v2; the remaining release-readiness work is consolidated in #816.

The final contract is:

• EQL v3 is the sole authoring and write generation.
• Existing EQL v2 ciphertext remains readable through the core native client.
• Final integrations use Encryption, the @cipherstash/stack-drizzle package root, and encryptedSupabase.
• The typed Encryption client supports audited decrypt, including through DynamoDB.
• @cipherstash/nextjs receives only package-specific release notes.
• Already-published RC changesets are not rewritten; still-pending entries and the final GA summary carry the corrected migration guidance and owning package metadata.

Remaining gate

#816 covers the last adapter correctness fixes and proof gates: nested PostgREST OR preservation, nullish-search fail-closed handling, safe non-row result modes, LIKE escaping, legacy Supabase call diagnosis, Date parity, examples/e2e/Drizzle integration typechecks, concrete Supabase domain guidance, and CLI/wizard skill parity including Prisma Next.

[coderdan]

The two deferred type-surface items share one root cause

#780's Not in this PR section defers encryptQuery in the published .d.ts collapsing its plaintext parameter to never under private-field type erasure, noting it is pre-existing on both remove-v2 and main.

While documenting the WASM entry for #754 (PR #777) I hit what looks like the same defect from the other side, and it is worth scoping the two together rather than separately.

Symptom A — cross-entry schema incompatibility. A schema authored with @cipherstash/stack/v3 does not typecheck against @cipherstash/stack/wasm-inline's Encryption, and the reverse fails too:

Type 'EncryptedTextSearchColumn' is not assignable to type 'AnyEncryptedV3Column'.
  Types have separate declarations of a private property 'columnName'.

Symptom B — the deferred one. Reproduced against a fresh dist/ build on 972a8a85:

TS2345: Argument of type '"alice@example.com"' is not assignable to parameter of type 'never'.

Both stem from the v3 column classes' type identity not surviving .d.ts emission intact — EncryptedV3Column carries private readonly columnName / private readonly definition (packages/stack/src/eql/v3/columns.ts:434-437), and TypeScript compares classes with private members nominally.

The obvious fix is wrong

Dropping private looks like a one-line fix and is not. columns.ts:426-433 says why:

the private definition field carries the literal eqlType/castAs/capabilities, so two otherwise-empty subclasses (e.g. EncryptedBooleanColumn and EncryptedDateColumn, both storage-only) are NOT mutually assignable. This nominality is what keeps plaintext inference precise.

Those privates are load-bearing — removing them would make storage-only domains mutually assignable and degrade the inference the v3 surface exists to provide. I had suggested exactly that fix in an earlier revision of #777's description and have since retracted it there.

The generalisable point for this issue

#780's own note on symptom B nails the reason neither surfaced: "invisible because the type tests import source rather than dist/."

That applies to every type-level claim in this stack, not just these two. Finding 13 in my review comment on #772 is a third case — Awaited<ReturnType<typeof EncryptionV3>> now silently resolves to the nominal client, so stack-drizzle's M1 guard became a duplicate of the next test while test:types stayed green; and tsc in that package reports hard TS2739s in five files nothing type-checks.

Given §"Before the rc.5 publish" already calls for a re-sweep of skills/ and the READMEs because nothing type-checks them, the analogous gate for the type surface is worth adding: at least one type test that consumes dist/ rather than src/. Without it, PRs 9–12 will land the authoring-surface changes with the same blind spot that let both of these through.

Happy to file symptoms A and B as a single issue against the type surface if that is more useful than carrying them here — flagging the connection first so they don't get scoped as two unrelated papercuts.