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

@@ -33,7 +33,7 @@ $COMPOSE exec -T db sh -c "exec mariadb-dump -u\"\$MARIADB_USER\" -p\"\$(cat /ru
   | gzip > "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz"
 
 echo "==> archiving uploads"
-$COMPOSE run --rm -T wordpress tar -czf - -C /var/www/html/wp-content uploads \
+$COMPOSE run --rm -T -u www-data wordpress tar -czf - -C /var/www/html/wp-content uploads \
   > "$BACKUP_DIR/uploads-${TIMESTAMP}.tar.gz"
 
 if [[ -n "${BACKUP_REMOTE:-}" ]]; then