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/restore.sh

@@ -31,7 +31,7 @@ gunzip -c "$DB_DUMP" | $COMPOSE exec -T db sh -c "exec mariadb -u\"\$MARIADB_USE
 echo "==> restoring uploads"
 ARCHIVE_DIR="$(cd "$(dirname "$UPLOADS_ARCHIVE")" && pwd)"
 ARCHIVE_NAME="$(basename "$UPLOADS_ARCHIVE")"
-$COMPOSE run --rm -T -v "${ARCHIVE_DIR}:/restore:ro" wordpress \
+$COMPOSE run --rm -T -u www-data -v "${ARCHIVE_DIR}:/restore:ro" wordpress \
   tar -xzf "/restore/${ARCHIVE_NAME}" -C /var/www/html/wp-content
 
 echo "==> restore complete — verify the site before treating the drill as passed"