Phase 2: deploy Authentik warm standby on the VPS

CNPG operator on the VPS (argocd-apps/vps-standby/cnpg-operator.yaml),
plus a CNPG 'replica cluster' for pg-authentik (infrastructure/
vps-standby/authentik/manifests/cnpg-cluster.yaml) that continuously
replays WAL shipped from home's pg-authentik via VPS MinIO's
cnpg-backups/pg-authentik bucket path - CNPG's native replica-cluster
mode, not a custom restore script like Vault needed (Vault has no
equivalent built-in continuous-replication-into-object-store feature).

The Authentik app itself runs at replicas: 0 in normal operation - the
replica DB is read-only until a deliberate manual promotion
(spec.replica.enabled: false), and a pod trying to write against a
read-only DB would just crashloop uselessly. values.yaml's authentik:
block is copied byte-identical from home's on purpose: the chart
deterministically derives its generated Secret's AUTHENTIK_SECRET_KEY
from these literal values.yaml strings, so both clusters land on the
same key without manually copying it - required since that key decrypts
things stored encrypted in the replicated DB.

infrastructure/vps-standby/authentik/manifests/cnpg-cluster.yaml

@@ -0,0 +1,68 @@
+---
+# CNPG "replica cluster" - continuously replays WAL shipped from home's
+# pg-authentik cluster (infrastructure/authentik/manifests/cnpg-cluster.yaml)
+# via VPS MinIO's cnpg-backups/pg-authentik bucket path. Unlike Vault's
+# raft-restore CronJob (Vault has no native continuous-replication-into-
+# object-store feature), CNPG's replica-cluster mode is a first-class
+# built-in mechanism - no custom restore scripting needed, matches the
+# plan's intent directly.
+#
+# While spec.replica.enabled is true, this cluster is a read-only standby
+# in continuous recovery - the -rw service exists but is NOT writable
+# (same "nothing accepts writes in normal operation" discipline as Vault/
+# Gitea). Promoting it to a real writable primary during an actual
+# incident is a deliberate manual step:
+#   kubectl -n authentik patch cluster pg-authentik --type merge \
+#     -p '{"spec":{"replica":{"enabled":false}}}'
+# then scale the authentik Deployment(s) up from 0.
+#
+# vps-minio-secret is a plain Secret copied here manually (kubectl, not
+# git) from the vps-minio-root-secret in the minio namespace - this
+# cluster has no Vault/ESO of its own:
+#   kubectl -n authentik create secret generic vps-minio-secret \
+#     --from-literal=accesskey=<vps minio root user> \
+#     --from-literal=secretkey=<vps minio root password>
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+metadata:
+  name: pg-authentik
+  namespace: authentik
+spec:
+  imageName: ghcr.io/cloudnative-pg/postgresql:16
+  instances: 1
+
+  resources:
+    requests:
+      memory: "256Mi"
+      cpu: "25m"
+    limits:
+      memory: "1Gi"
+      cpu: "250m"
+
+  storage:
+    size: 5Gi
+    storageClass: local-path
+
+  bootstrap:
+    recovery:
+      source: home-backup
+
+  externalClusters:
+    - name: home-backup
+      barmanObjectStore:
+        destinationPath: s3://cnpg-backups/pg-authentik
+        endpointURL: http://vps-minio.minio.svc.cluster.local:9000
+        s3Credentials:
+          accessKeyId:
+            name: vps-minio-secret
+            key: accesskey
+          secretAccessKey:
+            name: vps-minio-secret
+            key: secretkey
+
+  replica:
+    enabled: true
+    source: home-backup
+
+  monitoring:
+    enablePodMonitor: false  # no Prometheus on the VPS cluster