Slack: Stop unauthenticated requests from fataling the remaining webhook endpoints

[bor0]

Summary

• The #dotorg-alerts Slack channel reported repeated E_ERROR: Uncaught TypeError: hash_equals(): Argument #2 ($user_string) must be of type string fatals from community-deputies-calendly-webhook.php and trac-bot.php. Both pass $_GET['secret']/$_GET['token'] straight to hash_equals(), which requires a string in PHP 8 — a request like ?secret[]=x sends an array instead and fatals the endpoint rather than being rejected as invalid.
• security-team.php has the same defect and is fixed here too. It did not show up in the alert batch because its dispatcher only runs when the request URI contains /security-team.php?token=, which filters out a bare ?token[]=x. A request like ?token=a&token[]=x satisfies that substring check while PHP overwrites the value with an array, so the endpoint throws the same TypeError.
• announce.php, committers.php, and the array_combine() fatal in ticket.php reported in the same alert batch were already fixed by prior commits (announce.php/committers.php in ffdecba27, ticket.php in c05f7c3b4); this PR closes out the remaining call sites using the same guard pattern.

Notes

• The two endpoints that bootstrap WordPress (trac-bot.php, community-deputies-calendly-webhook.php) compare the value through wp_unslash(), because wp_magic_quotes() has already slashed $_GET by the time the guard runs. security-team.php only loads hyperdb, so its request data is never slashed and the comparison stays on the raw value, with the WPCS unslash sniff annotated the way committers.php does it.
• trac-bot.php's guard is split into a separate early return so all four webhook endpoints read alike. The calendly guard stays as a single condition, since splitting it would duplicate its header() + die() response in both branches.
• subgroup.php was checked and needs no change — its signature comes from $_SERVER headers, which are always strings.

Test plan

• php -l on all changed files
• PHPCS on the changed files introduces no new violations
• Confirm ?token[]=x / ?secret[]=x / ?token=a&token[]=x requests now return early instead of fataling in production

🤖 Generated with Claude Code

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props bor0, obenland.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[obenland]

Extended it to the remaining file and adjusted the checks to be in line with the prior fixes.

[obenland]

Not sure what happened in #815 (comment)

[obenland]

Oh, I know. @bor0 You need to create your PRs from a fork of this repo, not the repo itself. The hook that closes PRs when they get merged to meta SVN deletes all org-owned branches.

I merged #817 and it closed this one and #816 in one go.

[bor0]

Thanks — reopened from my fork as #821.