feat: add NEXT_PUBLIC_LOGIN_PROVIDERS env var to control visible login options

[leondape]

Problem

Self-hosted instances currently show all three login options (Google, Microsoft, SSO) with no way to control which are visible. For enterprise deployments using SSO, the Google/Microsoft buttons allow anyone to self-provision, bypassing organizational access control.

Chicken-and-egg problem with SSO-only deployments

SSO registration is only accessible via the /admin page, which requires:

1. Being logged in
2. Having your email in the ADMINS env var

But if you want SSO to be the only login method, you can't log in to set it up — because SSO isn't configured yet. The current workaround is:

1. Temporarily keep Google/Microsoft login enabled
2. Log in with Google/Microsoft to create your admin account
3. Set ADMINS=your@email.com and restart
4. Go to /admin, register the SSO provider
5. Set NEXT_PUBLIC_LOGIN_PROVIDERS=sso and restart again
6. Hope you never need to modify SSO settings without a Google/Microsoft escape hatch

This multi-restart bootstrap process is fragile and undocumented.

Proposed Solution

1. NEXT_PUBLIC_LOGIN_PROVIDERS env var

A comma-separated list of providers to show on the login page:

• NEXT_PUBLIC_LOGIN_PROVIDERS=sso — SSO only (enterprise lockdown)
• NEXT_PUBLIC_LOGIN_PROVIDERS=google,microsoft — no SSO button
• NEXT_PUBLIC_LOGIN_PROVIDERS=microsoft,sso — no Google
• Unset/empty — show all (current behavior, backwards compatible)

2. Solve the bootstrap problem (one of)

Option A: CLI/seed script for SSO registration
A pnpm sso:register command or Prisma seed script that creates the organization and SSO provider directly from the command line, without needing a running app or logged-in admin:

pnpm sso:register \
  --org-name "My Company" \
  --provider-id "my-company-saml" \
  --domain "mycompany.com" \
  --idp-metadata-file ./metadata.xml

This allows SSO-only deployments from the start, no temporary Google/Microsoft login needed.

Option B: First-run setup wizard
If no users exist in the database, show a setup wizard instead of the login page that lets the admin configure SSO (and create their admin account) before the app goes live.

Option C: Environment-based SSO registration
Allow SSO provider configuration entirely through env vars:

SSO_ORG_NAME=My Company
SSO_PROVIDER_ID=my-company-saml
SSO_DOMAIN=mycompany.com
SSO_IDP_METADATA_PATH=/path/to/metadata.xml

On startup, if these are set and no SSO provider exists, auto-register it. Simplest for Docker/Kubernetes deployments.

Additional Context

The tenant ID restriction (MICROSOFT_TENANT_ID) partially addresses access control for Microsoft-only orgs, but doesn't help for SSO-first workflows or mixed environments where authentication and email provider authorization should be separated.