feat(eql): absorb the EQL subsystem, and kill the version skew

.changeset/cli-install-sql-digest.md

@@ -0,0 +1,34 @@
+---
+'stash': patch
+---
+
+Verify the EQL install SQL against its release digest before running it.
+
+`stash eql install` reads the EQL v3 bundle from the resolved
+`@cipherstash/eql` in your `node_modules` and executes it against your
+database. That read was a bare `readFileSync` — nothing checked that the bytes
+on disk were the bundle the resolved release actually ships. A corrupt,
+partially-updated, or tampered package installed silently: the database ended
+up carrying SQL the version it reports does not define, and the CLI printed
+"EQL extensions installed."
+
+The CLI now hashes the bundle and compares it to `installSqlSha256` from the
+release manifest that ships alongside it, and **refuses** on a mismatch. The
+error names the expected digest, the actual digest, the resolved file path and
+the EQL version, so the remedy is visible rather than inferred. Verification
+happens before any database connection is opened, so a refusal means nothing
+was attempted — not that something was rolled back.
+
+The check covers all three paths that read the bundle: `stash eql install`,
+the SQL embedded by `stash eql migration --drizzle` / `--supabase`, and the
+expected-surface baseline `stash eql verify` compares your database against.
+`@cipherstash/stack-prisma` has verified against this same digest since its v3
+migrations landed; this brings the CLI in line.
+
+No healthy install is affected — the SQL and its manifest are produced by the
+same build of `@cipherstash/eql`, so a mismatch only ever means a broken
+dependency tree.
+
+`skills/stash-cli` documents the new pre-flight alongside the existing
+post-install surface check, so an agent reading it does not report a digest
+refusal as a failed install.

.changeset/eql-3-0-5-migration.md

@@ -0,0 +1,96 @@
+---
+'@cipherstash/stack-prisma': minor
+---
+
+Move the bundled EQL v3 migrations to **eql-3.0.5**, which renames the SQL
+function `eql_v3.ste_vec_contains` to `eql_v3.jsonb_document_contains`.
+
+**The blast radius is narrower than a renamed public function suggests.** The
+`@>` / `<@` operators on `public.eql_v3_json_search` behave exactly as before,
+and so do the two function-form entry points that exist for platforms without
+operator support — `eql_v3.jsonb_contains(jsonb, jsonb)` and
+`eql_v3.jsonb_contained_by(jsonb, jsonb)` are byte-identical to 3.0.4. Those
+are what a PostgREST caller invokes, so PostgREST callers on the documented
+surface are **not** affected. The renamed function is the typed implementation
+those operators dispatch into.
+
+**And the old name still works.** eql-3.0.5 ships `eql_v3.ste_vec_contains` as
+a deprecated delegating alias for both overloads, so hand-written SQL naming it
+— an application query, a view, an RLS policy, or a per-function
+`GRANT EXECUTE ON FUNCTION eql_v3.ste_vec_contains(…)` — keeps resolving. The
+typed overload stays inlinable, so a function-form query through the alias
+still matches the same functional GIN index. Migrate to
+`jsonb_document_contains` when convenient; nothing forces it at upgrade time.
+
+**Separately — and true of every EQL upgrade, not just this one:** the install
+bundle opens with `DROP SCHEMA IF EXISTS eql_v3 CASCADE`, so applying it drops
+every object in `eql_v3` / `eql_v3_internal` and everything that depended on
+them. **Encrypted data and column types are not affected** — the storage
+domains are `public.eql_v3_*`, deliberately outside both dropped schemas, and
+their CHECK functions are re-created rather than dropped. What does not survive
+is everything else pointing into the schema, which is two actions, neither of
+them to do with the rename:
+
+1. **Re-run your grant script.** Every grant on every `eql_v3` /
+   `eql_v3_internal` object is gone. The schema-wide form EQL documents —
+   `GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA eql_v3 TO app_role` — picks up
+   both the new name and the alias on its own.
+2. **Recreate your functional indexes, then `ANALYZE`.** Indexes over
+   `eql_v3.eq_term(…)` / `ord_term` / `match_term` / `to_ste_vec_query(…)`
+   depend on the dropped schema and go with it. Nothing errors afterwards:
+   encrypted predicates keep working and silently fall back to sequential
+   scans. A migration runner will not redo an already-applied migration, so
+   this has to be a *new* one. The `stash-indexing` skill documents the
+   mechanism ("These indexes do not survive an EQL reinstall or upgrade") and
+   the `EXPLAIN` check that confirms recovery; capturing and restoring them
+   automatically is tracked in
+   [cipherstash/stack#918](https://github.com/cipherstash/stack/issues/918).
+
+Any RLS policy, view, or constraint that calls an `eql_v3` function is dropped
+by the same CASCADE and needs recreating too. **The rename itself needs no
+action — the alias makes it non-breaking.**
+
+Two artefacts carry the new bundle:
+
+- A new upgrade edge, `20260814T0000_upgrade_eql_v3_3_0_5`, carrying the
+  invariant `cipherstash:upgrade-eql-v3-bundle-3.0.5-v1`. Databases already
+  running an earlier bundle re-install through this edge on the next
+  `prisma-next migration plan` followed by `prisma-next migrate`, exactly as
+  they did for 3.0.2 and 3.0.4. **`migrate` alone is not enough** — the seed
+  phase that copies a new migration package into your repo runs only from
+  `migration plan`, so without it the 3.0.5 directory never reaches disk and
+  `migrate` is a silent no-op that leaves the database on the older bundle.
+- The baseline install migration `20260601T0100_install_eql_v3_bundle`, whose
+  baked bundle moves to 3.0.5 and which gains a fourth no-SQL carrier op for
+  the new invariant. Fresh databases therefore land on 3.0.5 from the single
+  all-additive genesis edge, keeping `db init` (additive-only policy) working.
+
+**Action required.** The baseline's bytes — and so its `migrationHash` — have
+changed. If your project already has a `migrations/cipherstash/` directory
+generated against `@cipherstash/stack-prisma@1.0.0` or `@1.1.0`, delete that
+directory and re-run `prisma-next migration plan` (or `migrate`); the 1.1.0
+Prisma Next 0.17 upgrade re-anchored the same artefacts, so a space vendored
+against either release is stale here. The seed phase regenerates
+it byte-identical to the shipped artefacts. Your database keeps its markers, so
+already-applied invariants are not re-run — the only new work is the 3.0.5
+upgrade edge.
+
+If you skip the delete, nothing warns you: a vendored baseline is stale but
+internally intact, so it passes every integrity check. On an existing database
+the upgrade still applies correctly; on a **fresh** one, `db init` refuses with
+`Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is
+not allowed by policy.` — an error that names neither the directory nor the
+remedy. See "Upgrading from 1.0.0" in the package README.
+
+**Why the baseline was re-emitted rather than left frozen.** These artefacts are
+content-addressed and normally append-only: an EQL bump ships as a new upgrade
+directory and published directories are never rewritten. That rule cannot be
+followed here without a second `from: null` genesis edge, because no upgrade
+edge can ever be walked by `db init` — every upgrade edge is a self-edge, and
+the integrity checker requires a self-edge to carry a `data`-class op, which
+`db init`'s additive-only policy refuses. A fresh database must therefore
+collect every head-ref invariant from the genesis edge it walks. The
+append-only alternative would duplicate the full ~2.6 MB bundle into a new
+genesis edge on every EQL release, permanently; re-emitting was taken instead
+while 1.0.0 was two weeks old with negligible adoption, and is a decision to be
+re-argued on adoption numbers rather than repeated by default.

.changeset/eql-exact-runtime-pin.md

@@ -0,0 +1,41 @@
+---
+'@cipherstash/stack-prisma': patch
+'stash': patch
+---
+
+Pin the packed `@cipherstash/eql` dependency to an exact version, closing a
+route by which an installed EQL bundle could drift ahead of the code built
+against it.
+
+Both packages declared `"@cipherstash/eql": "workspace:^"` under
+`dependencies`. In this workspace that resolves in-tree either way, so nothing
+in development or CI could see a difference — but the two specifiers do not
+pack the same. pnpm rewrites the protocol when it builds the tarball a customer
+actually installs:
+
+    "workspace:^"  packs as  "^3.0.5"
+    "workspace:*"  packs as  "3.0.5"
+
+The caret is the problem. `@cipherstash/eql` is still published from
+`cipherstash/encrypt-query-language` until the publisher repoint, so a 3.0.x can
+reach npm without passing through this repository at all — and `^3.0.5` accepts
+it. A customer installing `stash` or `@cipherstash/stack-prisma` would then get
+SQL that STORES and queries encrypted payloads at one version, while
+`@cipherstash/stack`'s v3 domain types (which EMIT those payloads) and
+`stack-prisma`'s baked migrations stayed frozen at the version this repo built
+and tested against. The two halves of EQL are released in lockstep precisely
+because that skew does not fail at install or in CI — it fails in a database.
+
+`workspace:*` is the only form that closes it. A literal `"3.0.5"` would be an
+exact pin too, but it is a registry pin: `pnpm run lint:eql-pins` rejects it,
+because resolving EQL from a registry rather than from this repo is the same
+drift one layer up.
+
+No API, behaviour or SQL changes. What changes is the dependency range in the
+published tarballs, and only in the narrowing direction — the version resolved
+today is the version that was already being resolved. Nothing needs to be done
+on upgrade.
+
+`@cipherstash/stack` declares the same dependency under `devDependencies` and
+is deliberately left alone: pnpm rewrites that range too, but no consumer of the
+package ever resolves it.

.changeset/prisma-skill-upgrade-replan.md

@@ -0,0 +1,16 @@
+---
+'stash': patch
+---
+
+`skills/stash-prisma` now documents the re-plan step that follows an
+`@cipherstash/stack-prisma` upgrade: `rm -rf migrations/cipherstash && npx
+prisma-next migration plan`, why only `migration plan` vendors new migration
+packages, and the exact `db init` refusal a stale vendored directory produces on
+a fresh database (`Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class
+"data" which is not allowed by policy.`).
+
+The package README already carried this; the skill did not — and the skill is
+what ships inside the `stash` tarball and gets copied into a user's
+`.claude/skills/`, so an agent driving the upgrade hit the refusal with no route
+out of it. `packages/stack-prisma/test/v3/stale-vendored-space.test.ts` now pins
+both files to the planner's real message so they cannot drift apart again.

.changeset/protect-ffi-eql-bindings-in-tree.md

@@ -0,0 +1,35 @@
+---
+'@cipherstash/protect-ffi': patch
+---
+
+Compile `eql-bindings` from this repository rather than from crates.io.
+
+The native binding pinned `eql-bindings = "=3.0.2"` from the registry. It now
+resolves by path from `packages/eql/crates/eql-bindings`, which ships at 3.0.5
+alongside the `@cipherstash/eql` SQL bundle.
+
+**No behaviour change.** `eql-bindings` is the Rust half of EQL — it EMITS the
+encrypted payloads that the SQL half STORES and queries — and its Rust source is
+byte-identical across 3.0.2, 3.0.4 and 3.0.5 (`src/`, `bindings/` and `schema/`
+compared directly). What 3.0.3 through 3.0.5 changed was SQL, carried on the
+shared lockstep version number. So the payloads this binding produces are the
+same bytes before and after; what moves is the version stamped on the crate
+compiled into `index.node`, from 3.0.2 to 3.0.5.
+
+**Why it is worth a release anyway.** A registry pin let the two halves of EQL
+drift apart silently. Nothing asserted they agreed: a mismatched pair compiles,
+passes every suite, and fails in a database — because the failure is a payload
+the installed SQL cannot read, which no unit test holds both sides of. Resolving
+from the tree makes the skew unrepresentable: the emitter and the SQL are now
+the same commit, and `pnpm run lint:eql-pins` fails any change that reintroduces
+a registry pin on either.
+
+The flip was taken while it was a no-op deliberately. Waiting for the first
+release where the two halves genuinely diverge would have turned a provenance
+change into a behaviour change that had to be argued under credentialed test.
+
+Verified without credentials: `cargo build -p protect-ffi` clean, the crate test
+suite green (310 passed) with `cargo fmt --check` clean, and a
+`wasm32-unknown-unknown` build clean — the last of those being the target where a
+cross-workspace path dependency would break first, since the EQL workspace never
+otherwise builds for wasm32.

.changeset/skills-eql-source-and-index-cascade.md

@@ -0,0 +1,37 @@
+---
+'stash': patch
+---
+
+Correct two things the bundled agent skills were telling customers wrongly
+about EQL.
+
+**`skills/stash-postgres` pointed at the wrong repository.** EQL's source now
+lives in `cipherstash/stack` under `packages/eql/`, and that is where operator
+gaps and domain-level bugs are filed; only *publishing* still happens from
+`cipherstash/encrypt-query-language`, which the skill continues to say. The
+skill also cited "the EQL skill" as a source of truth that "ships from
+`encrypt-query-language` alongside the bundle" — no such skill ships from
+either repository, so the reference is gone and the remaining three sources
+(the generated types, the install SQL, and `SELECT eql_v3.version()`) are
+renumbered.
+
+**And it claimed the CLI pins an exact `@cipherstash/eql` version, "so a
+database is only ever on one bundle."** Neither half holds: the CLI depends on
+the workspace package rather than a pinned literal, and a database is on
+whatever bundle was last applied to it — the Prisma Next adapter installs and
+upgrades the bundle through its own migrations without involving the CLI at
+all. Replaced with the guarantee that does hold: one `stash` release carries
+one resolved bundle, and the database is the authority on which bundle it has.
+
+**`skills/stash-prisma` hands out the functional-index recipe without saying an
+EQL upgrade destroys it.** Installing a bundle begins with `DROP SCHEMA IF
+EXISTS eql_v3 CASCADE`, which cascade-drops every index over an `eql_v3.*`
+extractor — the PSL expression indexes Prisma Next 0.17 introduced and any
+`rawSql` index DDL alike; queries keep working and silently sequential-scan.
+Because an applied migration is never replayed, recovery is a NEW one: a PSL
+expression index has to change its `name:` (the physical name carries a content
+hash of the expression, so re-declaring the same one plans no work), and a
+`rawSql` recovery op needs a new `id`. Said where the recipe is given, pointing
+at `stash-indexing` for the mechanism and at
+[cipherstash/stack#918](https://github.com/cipherstash/stack/issues/918) for
+capturing and restoring them automatically.

.changeset/stack-prisma-upgrade-from-1-0-0.md

@@ -0,0 +1,16 @@
+---
+'@cipherstash/stack-prisma': patch
+---
+
+Document the 1.0.0 → 3.0.5 upgrade in the package README: why
+`migrations/cipherstash/` must be deleted and regenerated, what each Prisma Next
+command does if it is not, and the exact `db init` refusal
+(`Operation cipherstash.upgrade-eql-v3-bundle-3.0.5 has class "data" which is
+not allowed by policy.`) that a stale vendored directory produces on a fresh
+database.
+
+The behaviour worth knowing regardless of version: only `prisma-next migration
+plan` copies new migration packages into your repo. Running `migrate` or
+`db init` after upgrading this package without planning first silently leaves
+the database on the older EQL bundle — a stale vendored directory is internally
+intact, so it passes every integrity check and nothing reports a problem.

.changeset/supabase-skill-eql-305.md

@@ -0,0 +1,11 @@
+---
+'stash': patch
+---
+
+Update the bundled agent skills for eql-3.0.5. `skills/stash-supabase`
+re-states the PostgREST query-domain limitations against 3.0.5 (unchanged in
+substance — the typed `eql_v3.query_*` operand requirement still stands), and
+`skills/stash-postgres` drops one of the two places it claimed the CLI pins
+`@cipherstash/eql` to an exact version — a claim that stopped being true when
+EQL moved in-tree. The second copy goes in the same release, with the rest of
+that skill's EQL source and issue pointers.

.github/actionlint.yaml

@@ -10,3 +10,9 @@
 self-hosted-runner:
   labels:
     - blacksmith-4vcpu-ubuntu-2404
+    # Every job in the imported EQL suite. Sixteen of them, and the size is
+    # deliberate upstream: the sharded SQLx matrix compiles the full Rust
+    # dependency tree, so the runner is chosen for the compile rather than for
+    # the tests. Kept as its own label rather than renamed to the 4vcpu one —
+    # rehoming those jobs is a cost decision, not a lint fix.
+    - blacksmith-16vcpu-ubuntu-2204