Fix GitLab Authentik SSO: restore providers list, populate real provider key

GITLAB_OMNIBUS_CONFIG (gitlab_rails['omniauth_providers'] = [...]) is
an omnibus-Docker-image-only convention. This chart's CNG webservice
image never processes it - confirmed via gitlab/charts/gitlab/
templates/_omniauth.tpl, which only reads
global.appConfig.omniauth.providers (a list of {secret,key} refs, each
pointing at a Secret key holding a whole YAML-encoded provider block
loaded via Ruby's YAML.load_file). So GITLAB_OMNIBUS_CONFIG was always
a silent no-op on both home and VPS - neither ever actually had SSO
configured despite gitlab-oidc-secret existing and looking correct.

Yesterday's fix for 'FailedMount: references non-existent secret key:
provider' removed the providers: list entirely instead of populating
that key - stopped the crash, but also silently deleted the only real
OIDC config path on both sites (no error, login page just lost its SSO
button). This restores providers: on both, and gitlab-oidc-secret's
ExternalSecret template now actually renders a provider key containing
a real YAML provider block (with the templated client_id/secret
substituted in), matching what _omniauth.tpl expects.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

apps/gitlab/values.yaml

@@ -90,24 +90,18 @@ global:
   appConfig:
     # OmniAuth SSO Configuration
     #
-    # NOTE: no `providers:` list here (was `- secret: gitlab-oidc-secret,
-    # key: provider`) - found live 2026-08-21 (diagnosing the VPS GitLab
-    # deployment, which shares this same values shape) that the chart
-    # requires that secret to actually HAVE a `provider` key (a full
-    # omniauth provider config block, YAML-encoded) when this list is
-    # set, and gitlab-oidc-secret never had one - it only has
-    # GITLAB_OIDC_CLIENT_ID/SECRET, consumed via extraEnvFrom below and
-    # gitlab.webservice.extraEnv's GITLAB_OMNIBUS_CONFIG instead, which
-    # is the ACTUAL mechanism configuring the OIDC provider (this
-    # global.appConfig.omniauth.providers list was always redundant/
-    # unused for our setup). Silently didn't matter here at home because
-    # this Deployment hasn't restarted since gitlab-oidc-secret was last
-    # in whatever shape included that key (if it ever did) - Kubernetes
-    # doesn't re-validate already-mounted volumes when a Secret's shape
-    # changes, only NEW pod creation does, which is exactly why the VPS
-    # deployment (fresh pods, same values shape) hit it immediately
-    # ("FailedMount: references non-existent secret key: provider") while
-    # this one didn't - until its next restart.
+    # CORRECTED 2026-08-21 (second time - see git history for the wrong
+    # 2026-08-20 fix that removed this list entirely). This IS the real,
+    # actually-processed OIDC config mechanism for the CNG webservice
+    # image (chart's gitlab.appConfig.omniauth.configuration template,
+    # infra/_omniauth.tpl) - GITLAB_OMNIBUS_CONFIG below is an
+    # omnibus-image-only convention this image never processes, so it
+    # was always a documentation-only no-op despite looking functional.
+    # gitlab-oidc-secret's `provider` key now holds a full YAML-encoded
+    # provider block (apps/gitlab/manifests/external-secret-oidc.yaml),
+    # loaded via Ruby's YAML.load_file at container start - not raw
+    # client_id/secret strings, which is why plain GITLAB_OIDC_CLIENT_ID/
+    # SECRET keys alone (yesterday's assumption) were never enough.
     omniauth:
       enabled: true
       allowSingleSignOn: ['openid_connect']
@@ -115,6 +109,9 @@ global:
       autoLinkUser: ['openid_connect']
       syncProfileFromProvider: ['openid_connect']
       syncProfileAttributes: ['email', 'name']
+      providers:
+        - secret: gitlab-oidc-secret
+          key: provider
   
 # Settings for Let's Encrypt ACME Issuer - disabled, using cluster-wide cert-manager
 certmanager-issuer: