Run wp-cli as www-data instead of root; drop --allow-root

--allow-root was routing around wp-cli's own safety check rather than
addressing why root was there in the first place: docker exec defaults to
the container's root user because the image never sets a non-root user
for exec sessions — it was never about the actual web-facing attack
surface, which already runs as www-data (verified: php-fpm's worker
processes, the ones executing plugin/theme code for real requests, run as
uid 33, not root; only our own deliberate admin commands were root).

wp-config.php and the rest of wp-core are already owned by www-data (the
official entrypoint sets this up), so there's no actual reason for our
own commands to run as anything else. Verified: a full clean deploy and
a bookstore-core wp-cli command both work identically running as
www-data, no functional change, just removed an unnecessary privilege.

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

deploy/deploy.sh

@@ -44,6 +44,11 @@ grep -Ev '^(DB_PASSWORD|DB_ROOT_PASSWORD)=' "$ENV_FILE" > "$COMPOSE_ENV_FILE"
 # directory name, which every environment shares — that made staging quietly
 # reuse dev's db_data volume/credentials the first time this ran).
 COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${COMPOSE_ENV_FILE}"
+# wp-cli runs as www-data (who already owns wp-config.php etc.), not root —
+# `docker exec` defaults to root only because the image never sets a
+# non-root default user for exec sessions; the actual web-facing php-fpm
+# workers already run as www-data regardless.
+WP="$COMPOSE exec -T -u www-data wordpress wp"
 
 echo "==> writing DB secret files (bypasses compose's \${VAR} interpolation entirely)"
 SECRETS_DIR="secrets/${ENVIRONMENT}"
@@ -78,36 +83,35 @@ for i in $(seq 1 60); do
 done
 
 echo "==> ensuring WordPress is installed"
-if ! $COMPOSE exec -T wordpress wp core is-installed --allow-root; then
-  $COMPOSE exec -T wordpress wp core install \
+if ! $WP core is-installed; then
+  $WP core install \
     --url="${SITE_URL:?set SITE_URL in ${ENV_FILE}}" \
     --title="${SITE_TITLE:-Bookstore}" \
     --admin_user="${WP_ADMIN_USER:?set WP_ADMIN_USER in ${ENV_FILE}}" \
     --admin_password="${WP_ADMIN_PASSWORD:?set WP_ADMIN_PASSWORD in ${ENV_FILE}}" \
     --admin_email="${WP_ADMIN_EMAIL:?set WP_ADMIN_EMAIL in ${ENV_FILE}}" \
-    --skip-email \
-    --allow-root
+    --skip-email
 fi
 
 echo "==> installing/activating theme (Blocksy — free; Book Store starter site needs a manual license + import, see README)"
-$COMPOSE exec -T wordpress wp theme install blocksy --activate --allow-root
+$WP theme install blocksy --activate
 
 echo "==> installing/activating required plugins"
-$COMPOSE exec -T wordpress wp plugin install woocommerce redis-cache blocksy-companion --activate --allow-root
-$COMPOSE exec -T wordpress wp plugin activate bookstore-core --allow-root
-$COMPOSE exec -T wordpress wp redis enable --allow-root || true
+$WP plugin install woocommerce redis-cache blocksy-companion --activate
+$WP plugin activate bookstore-core
+$WP redis enable || true
 
 echo "==> enabling WooCommerce HPOS (custom order tables)"
-$COMPOSE exec -T wordpress wp option update woocommerce_custom_orders_table_enabled yes --allow-root
-$COMPOSE exec -T wordpress wp option update woocommerce_custom_orders_table_data_sync_enabled yes --allow-root
+$WP option update woocommerce_custom_orders_table_enabled yes
+$WP option update woocommerce_custom_orders_table_data_sync_enabled yes
 
 if [[ "$ENVIRONMENT" != "production" ]]; then
   echo "==> discouraging search engines (non-production)"
-  $COMPOSE exec -T wordpress wp option update blog_public 0 --allow-root
+  $WP option update blog_public 0
 fi
 
 echo "==> flushing caches and rewrite rules"
-$COMPOSE exec -T wordpress wp cache flush --allow-root
-$COMPOSE exec -T wordpress wp rewrite flush --allow-root
+$WP cache flush
+$WP rewrite flush
 
 echo "==> deploy complete: ${ENVIRONMENT}"