WasmClientConfig requires clientKey on every auth arm, so no browser-safe wasm client can be constructed

[tobyhede]

Surfaced while planning #708. This is the single blocker on browser support for every WASM surface, not just Supabase.

The finding

@cipherstash/stack/wasm-inline cannot construct a client without a clientKey, on any auth strategy:

// packages/stack/src/wasm-inline.ts:216-220
export type WasmClientConfig = {
  /** Workspace client identifier — required by the WASM client. */
  clientId: string
  /** Workspace client key — required by the WASM client. */
  clientKey: string
} & ( /* accessKey arm | authStrategy arm */ )

Both sit on the base of the type, so they are required on the authStrategy (OIDC federation) arm too — the arm that exists precisely so a browser never handles a workspace secret. And they are not merely type-level: both are forwarded unconditionally into wasmNewClient regardless of strategy (packages/stack/src/wasm-inline.ts:1380-1386).

clientKey is a workspace secret that must never reach a browser bundle. So the configuration the portable-runtime design prescribed for the browser — declared schemas + wasm + OidcFederationStrategy — is not constructible today.

Consequence for the portable-runtime series

Browser is untested and unclaimed across the whole series, and the shipped export map carries no browser condition. The design spec's browser sections are marked superseded on these grounds. Downstream of this issue, all of the following are blocked and deliberately absent rather than merely unscheduled:

• the browser export condition for @cipherstash/stack-supabase (Add the browser export condition to @cipherstash/stack-supabase, with a live browser smoke test #805),
• a live browser smoke test,
• any browser guidance in skills/stash-supabase/SKILL.md.

The question to answer

Can a wasm client be built for a browser at all?

• Is clientKey genuinely required by the Rust core under OIDC federation, or is it a leftover from the access-key path that the type over-declares?
• If it is required — is it a secret under federation, or an identifier whose exposure is acceptable when the actual authorisation comes from the federated JWT? The name says secret; the threat model has not been written down.
• If it is required and secret, browser support needs a different auth shape, and that is a Rust-side design job, not a JS one.

Answering this is cheap relative to what it unblocks, and the answer is currently guessed rather than known.

Related

OidcFederationStrategy is re-exported from wasm-inline (wasm-inline.ts:139-142) for exactly this browser use case, which is what makes the contradiction visible.