Supabase-backed product workflows

This section covers the supabase connector only; it does not depend on which identity provider signs the app's users in. Use Supabase through the supabase connector and ordinary workflow authoring; workflows do not need direct PostgreSQL access or SQL steps. Store required gateway headers as encrypted connector credentials. apikey is the public project key; Authorization carries the JWT for the intended database role. A tenant-wide connector credential cannot represent separate mobile users; never pass an app user's JWT as workflow input. Use an owner-binding RPC that maps immutable $caller when a workflow needs user-owned data. A protected server-to-server RPC may additionally require x-subkit-token, stored only on the connector. It authenticates SubKit to the product backend; it is not the end user's identity and never replaces the workflow's immutable $caller. Never put credentials in app code, workflow inputs or steps, client context, generated workflow source, or logs. Do not use service_role for caller-scoped access because it bypasses RLS. Bind product workflows to their product and required caller kind, derive owner identifiers from $caller, and fail closed when an atomic authorization or quota reservation does not explicitly permit the next step.