Optimize vault-restore: don't wait on condition=Ready (verified working already)

Confirmed end-to-end tonight: condition=Ready correctly times out every
cycle since Vault can't be Ready while sealed (the unseal step comes
right after this wait) - harmless via the existing || true fallback, but
wastes up to 2 minutes per restore cycle waiting on a condition that can
never be met at this point. Poll for the container process merely being
started instead.

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

infrastructure/vps-standby/vault/manifests/restore-cronjob.yaml

@@ -149,7 +149,19 @@ data:
     echo "==> Restarting Vault to fully reload post-restore state..."
     kubectl -n vault delete pod "$VAULT_POD"
     echo "==> Waiting for ${VAULT_POD} to come back..."
-    kubectl -n vault wait --for=condition=Ready "pod/${VAULT_POD}" --timeout=120s || true
+    # Not `kubectl wait --for=condition=Ready` - Vault's readiness probe
+    # requires unsealed state, which only happens in the step AFTER this
+    # wait (chicken-and-egg: it would never report Ready before we've had
+    # a chance to unseal it). Poll for the container process merely being
+    # started instead, which doesn't depend on any readiness probe.
+    for i in $(seq 1 24); do
+      PHASE="$(kubectl -n vault get "pod/${VAULT_POD}" -o jsonpath='{.status.containerStatuses[0].state.running}' 2>/dev/null || echo "")"
+      if [ -n "$PHASE" ]; then
+        echo "==> ${VAULT_POD} container is running."
+        break
+      fi
+      sleep 5
+    done
 
     echo "==> Unsealing with home's real key (restore overwrote the keyring)..."
     for i in 1 2 3 4 5; do