chore(deps): update wpcs to 3.4.1

[jason10lee]

Bumps wp-coding-standards/wpcs from 3.1.0 to 3.4.1 to pick up the fix for CVE-2026-45293.

Process note

CONTRIBUTING.md asks contributors to discuss a change via an issue or discussion before opening a PR, and I did not do that here. I opened this directly because it is a published-CVE fix in a dev dependency with no runtime or API surface, and the sweep it belongs to was time-boxed. If you would rather track it as an issue first, say so and I will open one and close this, or convert it — no attachment to this PR.

This is not a vulnerability in Remote Data Blocks, so SECURITY.md does not apply. The advisory is already public.

What changed and why

Every WPCS release from 0.14.1 up to (but not including) 3.4.1 carries CVE-2026-45293 (GHSA-3pwp-g2mj-5p3v, high severity). The WordPress.WP.EnqueuedResourceParameters sniff took a string lifted out of the file being scanned and passed it to eval(), so linting untrusted PHP could run code on whatever machine did the linting — a CI runner checking out a PR branch, or a developer's machine reviewing third-party code. This repo's ruleset pulls in WordPress-Extra, which turns that sniff on. 3.4.1 drops the eval() and analyses the tokens instead.

This touches the lockfile only and edits no composer.json. I regenerated it with:

composer update wp-coding-standards/wpcs -W --minimal-changes --no-install

-W is not optional here: 3.4.1 raises its own floor to phpcsutils ^1.2.3 and phpcsextra ^1.5.1, so a bare targeted update refuses to resolve.

Packages moved: wp-coding-standards/wpcs 3.1.0 → 3.4.1, phpcsstandards/phpcsutils 1.0.12 → 1.2.3, phpcsstandards/phpcsextra 1.2.1 → 1.5.1, squizlabs/php_codesniffer 3.13.4 → 3.13.5. Nothing else changes, and no package is added, removed or downgraded.

Because this repo was several minor versions behind on WPCS, the sniff set moves more than a single-version bump would. Expect new PHPCS findings on unrelated files; those are the newer standards applying rather than regressions from this change.

Note that #792 separately bumps automattic/vipwpcs to 3.1.0. The two do not conflict — vipwpcs 3.0.1 already permits wpcs ^3.1.0, so this PR needs no vipwpcs change either way.

How to test

1. Check out this branch and run composer install, then composer show wp-coding-standards/wpcs — it should report 3.4.1.
2. Run composer validate --no-check-all --no-check-publish and confirm the lock is in sync with composer.json.
3. Confirm the diff is lockfile-only: git diff --name-only trunk should list composer.lock and nothing else.
4. Confirm the patched sniff no longer evaluates scanned code: grep -n 'eval(' vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/EnqueuedResourceParametersSniff.php should return no eval() call, and grep -n 'function is_falsy' on the same file should match.
5. Run the repo's PHPCS task and check whether the newer sniff set surfaces findings that need a follow-up.

What I verified

composer validate --no-check-all reports the lock in sync with composer.json. A package-set comparison before and after shows no packages added, none removed, and no version downgrades; every changed package's dist.url resolves to api.github.com. I did not run PHPUnit or PHPCS in this repo, since no PHP changed and CI covers both.

Versioning and release are untouched — this changes a dev dependency only, so it needs no version bump under your semver process.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jason10lee]

Closing this as we skipped the issue-or-discussion step from CONTRIBUTING.md and there's an active Dependabot config here that should bring the update in on its own as a minor bump. See CVE-2026-45293 (GHSA-3pwp-g2mj-5p3v, high) for more information.