…ons-supabase

chore(redirects): temp redirect /integrations/supabase → current Supabase docs

… build

The EQL reference generator fetches the latest release's API.md at build time
and passes lowercase-led tags (e.g. `<tt>`) through as real HTML. MDX requires
every tag to be balanced, so a mangled SQL-comment source that emits an
unclosed `<tt>` fails the whole Vercel build — which is exactly what
eql-3.0.0-alpha.3 did (index.mdx:2153, `Expected a closing tag for <tt>`).

`<tt>` is Doxygen's teletype tag; MDX doesn't need it. Strip `<tt>`/`</tt>`
(non-code text only) before escaping, so malformed upstream docs degrade
gracefully instead of taking the deploy down.

Verified: regenerated content/stack/reference/eql/index.mdx from the live
eql-3.0.0-alpha.3 release and `next build` compiles all 329 pages.

fix(eql-docs): strip Doxygen <tt> tags so a stray one can't break the build

The live docs teach `new LockContext().identify(jwt)`. Per-operation CTS
tokens were removed in protect-ffi 0.25, so `identify()` is deprecated: it
still compiles and logs a warning, but the token it fetches is no longer
used by encryption operations. Readers copying these examples get code that
appears to bind an identity and does not.

Correct usage authenticates the client as the end user with
OidcFederationStrategy (config.authStrategy), then names the claim to bind:

  const client = await Encryption({
    schemas: [users],
    config: { authStrategy: OidcFederationStrategy.create(crn, () => getJwt()) },
  })
  await client.encrypt(v, opts).withLockContext({ identityClaim: ["sub"] })

Two pages also used `client.withLockContext({ identityToken })`, a call shape
that never existed in any release.

Verified against the shipped type definitions of @cipherstash/stack 0.19.0
and @cipherstash/auth 0.42.0.

docs: update identity-aware encryption to the strategy-based API

Follow-up to #57, from review feedback on the v2 port (#56).

The client setup blocks configure `authStrategy`, but the examples below
them import an already-built client, so a reader skimming the encrypt and
decrypt snippets sees `.withLockContext()` with no strategy in view and
could reasonably conclude the claim binding stands alone.

- Warn that OidcFederationStrategy is the only strategy supporting lock
  contexts. AccessKeyStrategy authenticates as the service, so there is no
  end-user identity for ZeroKMS to resolve the claim against.
- State that the examples depend on the authStrategy-configured client.
- Explain that `_` in the dashboard OIDC providers URL is the selected
  workspace.

Dropped the "AccessKeyStrategy is also re-exported" aside from identity.mdx:
naming it in a lock-context section was what invited the confusion.

…arifications

docs: clarify that lock contexts require OidcFederationStrategy

Brings the identity-API fixes (#57, #59) and the EQL docs build fix (#58)
into the v2 branch. Without this, merging v2 to main at launch would revert
them: v2's copy of content/stack still taught LockContext.identify(), which
is deprecated and no longer affects encryption.

One conflict, in scripts/generate-eql-docs.ts. Both branches carry the same
`<tt>`-stripping fix; they differ only in whether the .replace chain is
wrapped in parentheses. Kept v2's formatting.