fix: use mapfile array instead of xargs to preserve real phpcs exit code

[WayneRocha]

Problem

After #22 merged, phpcs CI still fails incorrectly when violations are found.

xargs translates phpcs exit code 1 (violations found) into exit code 123. GitHub Actions runs steps with bash -e by default, so when xargs returns 123 the step dies immediately — reviewdog never runs, no inline comments are posted, and the job fails with a cryptic exit code instead of the actual violations.

Practical impact:

• PRs with real phpcs violations get a job failure with exit code 123 and no inline comments
• Developers have no idea what they need to fix

Fix

Replace printf | xargs with mapfile to read CHANGED_FILES into a bash array. This:

• Gives us phpcs's real exit code (0 = clean, 1 = violations) instead of xargs's 123
• Uses || PHPCS_EXIT_CODE=$? to prevent bash -e from killing the step before reviewdog runs
• Still correctly handles filenames with spaces (each array element is one file path)

# Before
JSON_REPORT=$(printf '%s\n' "$CHANGED_FILES" | xargs -d '\n' vendor/bin/phpcs --report=json -q)
PHPCS_EXIT_CODE=$?   # always 123 when violations found, never 1

# After
mapfile -t FILES <<< "$CHANGED_FILES"
PHPCS_EXIT_CODE=0
JSON_REPORT=$(vendor/bin/phpcs --report=json -q "${FILES[@]}") || PHPCS_EXIT_CODE=$?

Test PRs

All affected repos have test PRs pointing to fix/phpcs-xargs-exit-code (updated from #22 test PRs).

Examples

the-events-calendar/the-events-calendar#5676
the-events-calendar/tribe-common#2939
the-events-calendar/event-tickets#4280
More in #22

[WayneRocha]

Even the bot started working returning to this formmating