Move all 8 Authentik OIDC client_secrets out of plaintext git

Completes the 'make the repo proper' cleanup from earlier this session -
these were flagged but deliberately not touched in 185e9c2 given the
blast radius (live SSO for 8 apps). User confirmed: fix all 8 now.

infrastructure/authentik/{argocd,gitlab,nextcloud,grafana,n8n,guacamole,
rancher,vault}-blueprint.yaml: converted from plain ConfigMap (client_secret
hardcoded) to ExternalSecret with a templated blueprint body
(client_secret: "{{ .clientSecret }}") pulling from Vault. Chart already
supports mounting blueprints from Secrets (blueprints.secrets, alongside
blueprints.configMaps) - infrastructure/authentik/values.yaml updated to
route these 8 there instead.

For argocd/nextcloud/n8n/guacamole/rancher: Vault already had the matching
value at secret/<app>-oauth (the APP side was already Vault-backed via its
own ExternalSecret) - the blueprint was the only remaining plaintext copy.

For gitlab/grafana/vault: Vault had no copy at all yet - created
secret/{gitlab,grafana,vault}-oauth with the EXISTING live values (not
rotated - these are the actual working credentials right now, rotating
would break login until every consumer is updated in lockstep, which is
out of scope for a cleanup pass). Also fixed the OTHER plaintext copies
that existed for these three specifically:
  - apps/gitlab/manifests/external-secret-oidc.yaml (new): replaces a
    manually kubectl-created, never-git-tracked gitlab-oidc-secret.
  - infrastructure/grafana/manifests/grafana-oauth-secret.yaml: was a
    plain Secret whose own comment said 'hardcoded from blueprint'.
  - infrastructure/vault/manifests/vault-init-{configmap,job}.yaml: this
    one COULDN'T be converted to the same ExternalSecret-from-Vault
    pattern - it's the PostSync Job that grants ESO's own Kubernetes-auth
    role in Vault, so ESO can't yet authenticate to pull anything from
    Vault at the point this script runs (genuinely circular). Sourced
    from a new vault-oidc-bootstrap Secret instead - created once
    manually (kubectl, not git, matching how Vault's own root/unseal
    material is already handled), independent of the ESO pipeline.

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

infrastructure/vault/manifests/vault-init-configmap.yaml

@@ -173,8 +173,22 @@ data:
       ttl="24h" >/dev/null
 
     # --- OIDC Auth (Authentik SSO) ---
-    OIDC_CLIENT_ID="9816a5ae7e7914b5d18f4ab939d011a98f8c8d6b3bb6777c46431afa06ac4a85"
-    OIDC_CLIENT_SECRET="ed2ba1c6378c7a46341b5162f39a7fab80e37596b01ed387c3719e8e0040344cf1daa307476c2e7a7f75041b3979275b1ebf00bb8bad94c864b4a38ded544f7b"
+    # OIDC_CLIENT_ID/SECRET used to be hardcoded here in plaintext - found
+    # and fixed 2026-08-20. Can't source this from Vault itself the way
+    # every other app's OIDC secret now does (infrastructure/authentik/
+    # vault-blueprint.yaml, secret/vault-oauth) - this job is what GRANTS
+    # ESO's own Kubernetes-auth role a few lines above
+    # (bound_service_account_names="...,external-secrets"), so ESO can't
+    # yet authenticate to Vault at the point this script runs - genuinely
+    # circular. Sourced from vault-oidc-bootstrap instead, a plain Secret
+    # created once manually (kubectl, not git):
+    #   kubectl -n vault create secret generic vault-oidc-bootstrap \
+    #     --from-literal=client_id=<same value as secret/vault-oauth> \
+    #     --from-literal=client_secret=<same value as secret/vault-oauth>
+    # envFrom on the Job (vault-init-job.yaml) injects these as
+    # VAULT_OIDC_CLIENT_ID/VAULT_OIDC_CLIENT_SECRET.
+    OIDC_CLIENT_ID="${VAULT_OIDC_CLIENT_ID:?VAULT_OIDC_CLIENT_ID not set - see vault-oidc-bootstrap secret}"
+    OIDC_CLIENT_SECRET="${VAULT_OIDC_CLIENT_SECRET:?VAULT_OIDC_CLIENT_SECRET not set - see vault-oidc-bootstrap secret}"
     OIDC_DISCOVERY_URL="https://auth.kube.huskypup.net/application/o/vault/"
 
     echo "==> Configuring OIDC auth (Authentik)..."