Fix wordpress-readiness race in deploy.sh

The bring-up wait only checked that php-cli runs, not that the official
image had finished copying WordPress's core files into the (possibly
freshly-emptied) wp_core volume — a step that takes a few real seconds on
first boot. On a fast pass through that window, wp-cli would run against
an empty /var/www/html and fail with "This does not seem to be a
WordPress installation," even though the container was otherwise healthy.
Now waits on wp-settings.php actually existing instead.

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

deploy/deploy.sh

@@ -53,13 +53,13 @@ chmod 644 "$SECRETS_DIR/db_password" "$SECRETS_DIR/db_root_password"
 echo "==> building and starting ${ENVIRONMENT}"
 $COMPOSE up -d --build
 
-echo "==> waiting for the wordpress container to come up"
-for i in $(seq 1 30); do
-  if $COMPOSE exec -T wordpress php -v >/dev/null 2>&1; then
+echo "==> waiting for WordPress core files (the official image copies them in on first boot of an empty volume, which takes a few seconds)"
+for i in $(seq 1 60); do
+  if $COMPOSE exec -T wordpress test -f /var/www/html/wp-settings.php >/dev/null 2>&1; then
     break
   fi
-  if [[ "$i" -eq 30 ]]; then
-    echo "wordpress container did not become ready in time" >&2
+  if [[ "$i" -eq 60 ]]; then
+    echo "wordpress core files did not appear in time" >&2
     exit 1
   fi
   sleep 2