Add CNPG ScheduledBackup for authentik/n8n/nextcloud - WAL archiving alone isn't restorable

Found while building the VPS replica clusters (Phase 2): all three
CNPG clusters' backup.barmanObjectStore blocks only configure continuous
WAL archiving. CNPG's bootstrap.recovery needs at least one real Backup
object in the object store before it has anything to restore -
'no target backup found', confirmed live against pg-authentik. This gap
was systemic (gitlab has it too, not fixed here - out of scope for
tonight, no VPS standby depends on it).

immediate: true fires one backup right away in addition to the daily
01:00 schedule, to unblock the in-progress VPS restore now rather than
waiting up to 24h for the first scheduled run.

infrastructure/authentik/manifests/scheduled-backup.yaml

@@ -0,0 +1,26 @@
+---
+# Found 2026-08-18 while building the VPS Authentik replica cluster: the
+# barmanObjectStore backup: block on cnpg-cluster.yaml only configures
+# continuous WAL archiving - it does NOT itself produce a restorable base
+# backup. CNPG's bootstrap.recovery (used by
+# infrastructure/vps-standby/authentik/manifests/cnpg-cluster.yaml) needs
+# at least one actual Backup object to exist before it has anything to
+# restore ("no target backup found" otherwise, confirmed live). This gap
+# was systemic - n8n, nextcloud, and gitlab all had the same WAL-only
+# setup with no ScheduledBackup anywhere in the repo.
+#
+# immediate: true also fires one backup right away on creation, not just
+# on the schedule - needed to unblock the VPS restore immediately rather
+# than waiting up to 24h for the first scheduled run.
+apiVersion: postgresql.cnpg.io/v1
+kind: ScheduledBackup
+metadata:
+  name: pg-authentik-backup
+  namespace: authentik
+spec:
+  schedule: "0 1 * * *"  # daily 01:00 - ahead of the VPS's other restore/replay jobs
+  backupOwnerReference: self
+  immediate: true
+  method: barmanObjectStore
+  cluster:
+    name: pg-authentik