Revisit exact-version pinning for PHPCS dependencies

Splitting this out of #283 / #282 so the security fix ships without being held up by a policy debate.

What happened

wp-coding-standards/wpcs shipped a security patch (3.4.1, CVE-2026-45293). Because composer.json pins "wp-coding-standards/wpcs": "3.4.0" exactly, two things followed:

1. Consumers could not pick up the patch on their own — it needed a Dependabot PR, a CHANGELOG PR, and a signed 7.0.1 tag here first.
2. More sharply: Composer 2.10 blocks advisory-affected versions by default (policy.advisories.block), so the pin made released 7.0.0 fail to resolve at all:

- Root composer.json requires wp-coding-standards/wpcs 3.4.0 … not loaded,
  because they are affected by security advisories ("PKSA-mh9b-91zm-m1gy")

A pinned dependency becoming advisory-affected now breaks installation of our package outright, not just its security posture. That failure mode did not really exist when the pinning policy was written.

The tradeoff

The pin is deliberate — 7.0.0's CHANGELOG states "Dependencies stay pinned to exact versions (as before) so the standard lints reproducibly." That goal is real: a PHPCS minor can add sniffs and turn a green build red without any change on our side.

The counter-argument is where reproducibility belongs. This is a library, and we deliberately don't commit composer.lock (CI resolves fresh, see ci.yml). Reproducibility for a library is normally the consumer's lockfile, not the library's constraints — pinning here buys reproducibility for everyone at the cost of making us a mandatory release bottleneck for every upstream patch.

Options

• Keep exact pins. Accept the release bottleneck. Mitigate by treating Dependabot security PRs as same-day releases.
• ~3.4.1 (patch-only drift). Security and bug patches flow to consumers immediately; minors like 3.5.0 still require a deliberate bump here, so the "new sniffs break the build" risk stays contained. Applies equally to squizlabs/php_codesniffer, slevomat/coding-standard, phpcompatibility/phpcompatibility-wp, sirbrillig/phpcs-variable-analysis.
• ^3.4.1. Maximum flexibility, but reintroduces exactly the minor-drift breakage the pinning policy was meant to prevent. Probably not worth it.

~3.4.1 looks like the right middle ground, but it is a policy call for the team rather than something to slip into a security release.

Worth deciding either way, since the next upstream advisory will reproduce the same install breakage.

🤖 Generated with Claude Code

Start with composer.json and ci.yml, then review the pinning policy in the 7.0.0 CHANGELOG and the related discussions in #282 and #283. Compare the dependency constraint options and their release implications. Done means the team has selected a policy and the relevant constraints and release guidance reflect that decision.