Phase 4c: Intercept non-SSO logins for enforced domains

[GregorShear]

• Add enforce_sso boolean column to tenants.
• GoTrue customize_access_token hook (check_sso_requirement) blocks social login for users whose email domain matches an SSO-enforcing tenant's configured domain in auth.sso_domains.
• The hook checks auth.users.is_sso_user — SSO users always pass through (important for token refresh).
• Blocked logins receive a 403 error with message: 'sso_required:<domain>' — the frontend parses the domain and calls supabase.auth.signInWithSSO({ domain }) to redirect the user to their IdP.

Users whose email domain does NOT match an enforcing tenant's SSO domain (e.g., contractors with @gmail.com) are not blocked by the hook. Their grants on enforcing tenants are handled by grant filtering in 4d instead.

Activated by enforce_sso = true. Tenants configure SSO first, then communicate the transition to their users. enforce_sso is flipped on a hard cutoff date.

Verify:

• Social user with matching email domain on enforcing tenant → blocked with sso_required:<domain>
• Social user with matching domain, enforce_sso = false → not blocked
• Social user with non-matching domain (e.g. @gmail.com) → not blocked (grants handled by 4d)
• SSO user (is_sso_user = true) with matching domain → not blocked (token refresh works)
• Blocked user redirected via signInWithSSO({ domain }) → authenticates via IdP → grant migration trigger fires
• Malformed hook input → exception caught, login not blocked, warning logged

[GregorShear]

Looking for input here - should we block or pass users on exception? do we favor breaking login, or adding a security hole?

either way i'll need help setting up an alert for that warning.