feat(backup): the overlay picks the credential — BACKUP_CREDENTIALS_SUFFIX

The previous commit created the two halves. This one wires the choice, so dev renders MinIO
credentials and prod renders R2 credentials from the SAME base manifests (R-ENV-02: the
overlay patch is the entire difference between environments; no base manifest is forked).

    cluster-vars  BACKUP_CREDENTIALS_SUFFIX   base ""  |  dev ""  |  prod "-prod"

    velero HelmRelease  credentials.existingSecret: velero-cloud-credentials${BACKUP_CREDENTIALS_SUFFIX}
    3x CNPG Cluster     s3Credentials.*.name:      <db>-backup-credentials${BACKUP_CREDENTIALS_SUFFIX}

ONE SUFFIX, NOT FOUR SECRET-NAME KNOBS. Four independent knobs can be updated three-quarters
of the way, leaving one consumer reading the OTHER environment's key with nothing rendering
wrong — and StrictPostBuildSubstitutions cannot catch that: strict mode fails on an UNDEFINED
variable, never on a defined-but-stale one. With one suffix the four move together or not at
all. The cost is that the rendered Secret name is not greppable from the consumer, so both
kustomizations spell the two names out in full beside the resources.

THE BASE DEFAULT IS "" AND THAT IS LOAD-BEARING. It renders the UNSUFFIXED names — objects
that exist in every render, and that dev is running today. The alternative failure mode is
strictly worse than the shared-Secret state this replaces: velero's pod hangs in
ContainerCreating forever when `existingSecret` names a missing Secret (the volume never
mounts), and a CNPG Cluster whose s3Credentials Secret is absent stops archiving WAL — which
under archive_mode=on is a filling pgdata PVC, not a missing backup. So an unresolvable
default breaks the referencing cluster HARDER than a wrong key does. Both overlays state the
value explicitly anyway, so neither inherits it silently.

Prod's overlay change is a cluster-vars op only. The velero Flux Kustomization patch is
untouched (it stays decryption-only, and velero stays suspended on prod).

VERIFIED — `kubectl kustomize --load-restrictor LoadRestrictionsNone` on clusters/dev and
clusters/prod for the cluster-vars values, then on each of the four affected tiers (platform,
platform-config, platform/velero, apps/wave-0) piped through `flux envsubst --strict` with
that environment's variables:

  strict envsubst              PASSES for all 8 (env x tier) combinations
  dev   velero existingSecret  velero-cloud-credentials
  dev   keycloak/nextcloud/semaphore-db  <db>-backup-credentials         (both key refs each)
  prod  velero existingSecret  velero-cloud-credentials-prod
  prod  keycloak/nextcloud/semaphore-db  <db>-backup-credentials-prod    (both key refs each)
  both  all EIGHT Secret objects present in the rendered output (dev and prod alike)
  no `${...}` survives in any rendered tier except gitea's three DELIBERATE `$${...}` shell
    escapes in apps/wave-0, which are pre-existing and unrelated.

Read alongside the endpoints the same overlays already set, the two environments are now
isolated on credential AND target:
  dev   velero s3://velero (root) + cnpg s3://cnpg      @ http://192.168.1.9:9000  region us-east-1
  prod  velero k3s-prod-backup/velero + barman prefix   @ https://<acct>.r2.cloudflarestorage.com  region auto

Co-Authored-By: Claude Opus 5 <[email protected]>

platform/keycloak/postgres-cluster.yaml

@@ -58,12 +58,19 @@ spec:
     barmanObjectStore:
       destinationPath: ${CNPG_BACKUP_PATH}
       endpointURL: ${S3_BACKUP_ENDPOINT}
+      # PER-ENVIRONMENT credential (2026-09-07): dev reads keycloak-db-backup-credentials (MinIO),
+      # prod reads keycloak-db-backup-credentials-prod (Cloudflare R2). Both Secrets are applied to
+      # both clusters by platform/keycloak/kustomization.yaml; ${BACKUP_CREDENTIALS_SUFFIX} (dev ""
+      # | prod "-prod") picks one. Before the split these were ONE shared Secret, so writing prod's
+      # R2 token into it would have left dev signing MinIO requests with an R2 key — a 403 on every
+      # archive command, which under archive_mode=on is the disk-full clock described above, not a
+      # missing backup.
       s3Credentials:
         accessKeyId:
-          name: keycloak-db-backup-credentials
+          name: keycloak-db-backup-credentials${BACKUP_CREDENTIALS_SUFFIX}
           key: ACCESS_KEY_ID
         secretAccessKey:
-          name: keycloak-db-backup-credentials
+          name: keycloak-db-backup-credentials${BACKUP_CREDENTIALS_SUFFIX}
           key: ACCESS_SECRET_KEY
       wal:
         compression: gzip

platform/velero/helmrelease.yaml

@@ -114,7 +114,14 @@ spec:
             # here first.
             checksumAlgorithm: ""
     credentials:
-      existingSecret: velero-cloud-credentials   # SOPS Secret carrying the `cloud` INI key (ns velero)
+      # PER-ENVIRONMENT credential (2026-09-07). dev renders velero-cloud-credentials (the scoped
+      # MinIO key); prod renders velero-cloud-credentials-prod (the Cloudflare R2 token). BOTH
+      # Secrets are applied to BOTH clusters by platform/velero/kustomization.yaml — the suffix
+      # only chooses which one this Deployment mounts. cluster-vars: BACKUP_CREDENTIALS_SUFFIX,
+      # dev "" | prod "-prod". A name that resolves to a MISSING Secret does not degrade the
+      # backup, it wedges the pod in ContainerCreating (the volume never mounts), which is why
+      # the base default is the empty suffix — the unsuffixed Secret always exists.
+      existingSecret: velero-cloud-credentials${BACKUP_CREDENTIALS_SUFFIX}   # SOPS Secret carrying the `cloud` INI key (ns velero)
     # --- Daily backups. TWO schedules implement the opt-out volume policy: capture every PVC's data
     #     by default (opt-out), but skip the two reconstructable heavy volumes' DATA while still
     #     capturing their Kubernetes resources. ---