Configure the external OIDC auth provider via env vars (align with GitHub/Google SSO)

[midigofrank]

Background

This PR (#4621) introduced SSO sign-in for GitHub and Google, configured entirely through environment variables. The pre-existing external/generic OIDC provider is still configured the old way — a database row (AuthConfig) managed through an admin UI. We now have two parallel mechanisms for the same concept. This issue proposes migrating the external provider to env-var configuration so all SSO providers are configured consistently, and retiring the DB/admin-UI path.

Current state

GitHub/Google (env-based):

• SSO_GITHUB_* / SSO_GOOGLE_* read in lib/lightning/config/bootstrap.ex:506-530
• Handlers built by GithubHandler.build/0 / GoogleHandler.build/0 (reading Config.github_oauth/1 / google_oauth/1)
• Registered into the handler cache by AuthProviders.CacheWarmer
• Redirect URI derived automatically via sso_redirect_uri/4 (bootstrap.ex:1054)

External provider (DB-based):

• AuthConfig schema -> auth_providers table (lib/lightning/auth_providers/auth_config.ex)
• Configured via admin UI: /settings/authentication[/new] (router.ex:232-233), AuthProvidersLive.Index, AuthConfigForm, live/auth_providers/form_component.ex
• Loaded by CacheWarmer via AuthProviders.get_existing/0; served through get_handler/1 -> find_and_build/1 -> Handler.from_model/1
• Surfaced on the login page via get_existing/0 (user_session_controller.ex:123)
• Limited to one provider row (get_existing/0 uses Repo.one)

Goal

Configure the external OIDC provider through environment variables (mirroring GitHub/Google) and remove the DB-backed configuration + admin UI.

Proposed shape (starting point - open to discussion)

• New vars, e.g. SSO_OIDC_NAME, SSO_OIDC_CLIENT_ID, SSO_OIDC_CLIENT_SECRET, plus either a discovery URL or explicit endpoints (see open questions), read in bootstrap.ex
• A Config.oidc_oauth/1 accessor + an OidcHandler.build/0 analogous to the GitHub/Google handlers
• Redirect URI derived from the configured name via sso_redirect_uri/4
• Register it in CacheWarmer alongside the others

Touchpoints to migrate / remove

• Admin UI: router.ex:232-233, AuthProvidersLive.Index, AuthConfigForm, live/auth_providers/form_component.ex, auth_providers_live_test.exs
• auth_providers.ex: get_existing/{0,1}, create/1, update/2, delete!/1, the DB branch of CacheWarmer
• AuthConfig schema + auth_providers table (drop migration, or deprecate first)
• Login-button logic in user_session_controller.ex
• setup_utils.ex (referenced in teardown) and any seeds
• DEPLOYMENT.md SSO section

Open questions / decisions

• Discovery URL vs. explicit endpoints? Either provide a single SSO_OIDC_DISCOVERY_URL (fetched into a WellKnown at boot - one var, always in sync with the IdP, but requires the .well-known doc to be reachable), or have operators set the three endpoints directly - SSO_OIDC_AUTHORIZATION_ENDPOINT, SSO_OIDC_TOKEN_ENDPOINT, SSO_OIDC_USERINFO_ENDPOINT (no network fetch, mirrors how the GitHub/Google handlers already construct WellKnown, but more vars and they can drift from the IdP).
• Fixed provider name vs. configurable (SSO_OIDC_NAME)? The name drives the callback path /authenticate/<name>/callback, so changing it requires re-registering the redirect URI at the IdP.
• Support multiple external providers, or keep the current single-provider limit?
• Back-compat: existing self-hosted installs with a DB-configured provider would need to move their config to env vars on upgrade - do we drop the table immediately or deprecate over a release?

Related: #4621