fix: wait for Postgres before starting backend

The CNPG Cluster takes ~25-30s to bootstrap initdb, but the backend
Deployment is applied at the same time as the Cluster. The new Backstage
backend attempts its database connection once at startup; on failure it
stays up in a degraded state (liveness 200, readiness 503) instead of
crash-looping, so Kubernetes never restarts it and the rollout never
completes. This failed the kind e2e and would equally strand the pod in
production, where Flux applies the Cluster and Deployment together.

Add a wait-for-postgres initContainer to the database-cnpg component so
the backend only starts once Postgres accepts connections. It reuses the
CNPG image (pg_isready, already cached on the nodes) and mirrors the
hardened container securityContext.

Author: scotwells

config/components/database-cnpg/patch-deployment.yaml

@@ -5,6 +5,35 @@ metadata:
 spec:
   template:
     spec:
+      initContainers:
+        - name: wait-for-postgres
+          image: ghcr.io/cloudnative-pg/postgresql:17
+          command:
+            - sh
+            - -c
+            - until pg_isready -h "$POSTGRES_HOST" -p "$POSTGRES_PORT" -U "$POSTGRES_USER"; do echo "waiting for postgres at $POSTGRES_HOST:$POSTGRES_PORT"; sleep 2; done
+          env:
+            - name: POSTGRES_HOST
+              valueFrom:
+                secretKeyRef:
+                  name: backstage-postgres-app
+                  key: host
+            - name: POSTGRES_PORT
+              valueFrom:
+                secretKeyRef:
+                  name: backstage-postgres-app
+                  key: port
+            - name: POSTGRES_USER
+              valueFrom:
+                secretKeyRef:
+                  name: backstage-postgres-app
+                  key: username
+          securityContext:
+            allowPrivilegeEscalation: false
+            readOnlyRootFilesystem: true
+            capabilities:
+              drop:
+                - ALL
       containers:
         - name: backstage
           env: