fix(backup): retry pg_dump connection to survive NetworkPolicy sync lag

Live testing showed pg_dump got "Connection refused" immediately at job
start, but a manual pg_isready/psql from an identically-labeled pod a few
seconds later succeeded fine every time. The cluster's NetworkPolicy
controller needs a brief moment to program a brand-new pod's IP into the
target's allowed ingress rules; a job that starts dumping instantly can
race that window. backup.sh now waits for pg_isready before each pg_dump
(up to 15 tries / ~30s) instead of assuming connectivity is ready at
container start.

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

apps/authentik/authentik-backup.yaml

@@ -33,7 +33,7 @@ spec:
           restartPolicy: OnFailure
           containers:
             - name: backup
-              image: rohana.axion1337.de/sorb/axion-backup:v1
+              image: rohana.axion1337.de/sorb/axion-backup:v2
               env:
                 - name: BORG_REPO
                   value: "ssh://u641795@u641795.your-storagebox.de:23/./authentik-backup"

apps/production/synapse-backup.yaml

@@ -35,7 +35,7 @@ spec:
           restartPolicy: OnFailure
           containers:
             - name: backup
-              image: rohana.axion1337.de/sorb/axion-backup:v1
+              image: rohana.axion1337.de/sorb/axion-backup:v2
               env:
                 - name: BORG_REPO
                   value: "ssh://u641795@u641795.your-storagebox.de:23/./synapse-backup"