Reintroduce Supabase integration tests against a containerised Supabase

[coderdan]

Context

supabase.test.ts (in packages/protect and packages/stack) was disabled in CI as part of #477 — it needs a live Supabase project (SUPABASE_URL + SUPABASE_ANON_KEY, plus Postgres for fixture DDL) and could not move to the containerised Postgres the rest of the Test JS suite now uses. It currently describe.skipIfs itself when the Supabase environment is absent.

Background: the Test JS CI / EQL version-coupling incident (see the incident post-mortem).

Goal

Bring the Supabase integration tests back into CI, running reproducibly against an ephemeral, pinned, containerised Supabase — the same principle applied to the plain-Postgres suite in #477. No shared external project.

Approach

• Use the Supabase CLI local stack (supabase start / the supabase/setup-cli action) to spin up Supabase in Docker in CI — likely a dedicated job, since the full stack (Postgres, Auth, PostgREST, Kong, …) is heavier than a single Postgres container.
• Install a pinned EQL into its Postgres using the Supabase-specific bundle (cipherstash-encrypt-supabase.sql — Supabase needs the -supabase / -no-operator-family variant, not the standard one).
• Point supabase.test.ts at the local stack's URL / anon-key and remove the skip guard added in ci: run Test JS integration tests against a pinned postgres-eql container #477.

Considerations

• Pin the Supabase EQL bundle to the same EQL version as the rest of CI; bump in lockstep.
• Re-calibrate after the EQL 2.3 upgrade (feat: upgrade protect-ffi to 0.23.0 #473).
• Decide whether both the protect and stack copies of supabase.test.ts are still needed.

Acceptance criteria

• supabase.test.ts runs in CI against a containerised, version-pinned Supabase + EQL — no shared external Supabase project.
• The describe.skipIf guard from ci: run Test JS integration tests against a pinned postgres-eql container #477 is removed.
• The EQL version is pinned and bumped in lockstep with the rest of the stack.