fix(stack-prisma): db init fails PN-RUN-3020 on fresh databases — EQL install op is classed `data` under an additive-only policy

[coderdan]

Summary

prisma-next db init enforces an additive-only operation policy, but the cipherstash contract space's install-eql-v3-bundle op is classed data. Every fresh-database init of an app using @cipherstash/stack-prisma therefore fails:

PN-RUN-3020: Operation cipherstash.install-eql-v3-bundle has class "data"
which is not allowed by policy. Policy only allows: additive.

This blocks Prisma Compute's GitHub preview deploys, which run db init against a fresh branch database on every push. Found in a live dogfooding run (rc.4 consumer app + Compute push-to-deploy).

Reproduce

1. Consumer app using @cipherstash/stack-prisma with a vendored migrations/cipherstash/ space
2. Point it at a fresh (empty) Postgres database
3. prisma-next db init
4. Fails with PN-RUN-3020 above. prisma-next migrate succeeds on the same database — its policy allows all operation classes.

Root cause

The data class was chosen to satisfy the aggregate integrity checker's no-op self-edge rule (sameSourceAndTarget, PN-MIG-CHECK-007). Verified against migration-tools 0.16.0: that rule only fires when from === to. The install edge is the genesis edge — it runs from: null → the empty-storage hash, so it is not a self-edge and additive passes the checker.

additive is also the truthful class on the policy axis: the bundle only CREATEs its own schemas, domains, and functions, so it cannot damage user data.

Confirmed empirically both ways — flipping a true A → A upgrade self-edge to additive trips PN-MIG-CHECK-007; flipping the install edge does not.

Constraint

The EQL upgrade edges are true self-edges and must keep data. So the re-emitted install edge has to carry every upgrade invariant itself (no-SQL additive carrier ops) — legitimate because the baked bundle already IS the pinned release, a superset of every earlier v3 surface. That lets computeExtensionSpaceApplyPath satisfy the head ref from the single all-additive genesis edge, so fresh databases never need to walk a data-classed edge.

Notes

Fixing this requires a one-time re-emit of a published migration artefact, changing both the install package's migrationHash and its baked installSqlSha256. That is only acceptable pre-GA, and RC consumers with a vendored migrations/cipherstash/ must delete the space directory and re-run prisma-next migration plan.

Fixed by #820, which also pins the baked bundle to eql-3.0.4.