Fix GitLab OIDC secret FailedMount blocking webservice/sidekiq startup

Real bug affecting both home and VPS GitLab, found live diagnosing why
VPS's webservice pod was stuck at Init:0/3 for 74+ minutes (surfacing as
404s - nothing was ever actually serving):

global.appConfig.omniauth.providers: [{secret: gitlab-oidc-secret, key:
provider}] requires that secret to have a 'provider' key (a full YAML
omniauth provider config) - gitlab-oidc-secret never has one, only
GITLAB_OIDC_CLIENT_ID/SECRET, which get consumed via extraEnvFrom +
GITLAB_OMNIBUS_CONFIG's gitlab_rails['omniauth_providers'] instead (the
actual, complete mechanism already configuring OIDC - this providers:
list was always redundant). Removed it from both values.yaml files.

Home's GitLab has run fine so far because Kubernetes doesn't re-validate
already-mounted volumes when a referenced Secret's shape changes -
webservice/sidekiq there just haven't restarted since gitlab-oidc-secret
was last (if ever) in a shape with that key. VPS's identical values
shape hit it immediately on first pod creation. This was a live landmine
for home too - fixed before it could bite on a future restart.

Also: global.kas.enabled: false added to the VPS values (gitlab.kas.enabled
alone doesn't stop KAS pods - found live, separate toggle).

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

apps/gitlab/values.yaml

@@ -89,6 +89,25 @@ global:
   # Application Configuration
   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.
     omniauth:
       enabled: true
       allowSingleSignOn: ['openid_connect']
@@ -96,9 +115,6 @@ 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: