Repair wp/5.8 branch Actions: Configure the Composer advisory policy - #84442

Part of #82935.

What?

Adds a config.policy.advisories.ignore-id block to composer.json for PKSA-mh9b-91zm-m1gy, with the reason it doesn't apply as its description.

Why?

Current Composer releases refuse to load package versions covered by a security advisory during resolution. Every wp-coding-standards/wpcs release that satisfies this branch's ^2.2 requirement is covered by one, so composer update fails outright:

Problem 1
  - Root composer.json requires wp-coding-standards/wpcs ^2.2, found wp-coding-standards/wpcs[2.2.0, 2.2.1, 2.3.0] but these were not loaded, because they are affected by security advisories ("PKSA-mh9b-91zm-m1gy").

• PKSA-mh9b-91zm-m1gy (CVE-2026-45293) — an eval()-injection bug in wp-coding-standards/wpcs' WordPress.WP.EnqueuedResourceParameters sniff. That sniff ships only in the WordPress and WordPress-Extra rulesets. This branch's phpcs.xml.dist pulls in WordPress-Core and WordPress-Docs plus a handful of individually-named sniffs, and references neither of those two rulesets, so the vulnerable sniff is never loaded at any wpcs version.

It is the only ID this branch's dependency graph trips — with it ignored, resolution completes.

This branch commits a composer.lock, and composer install from a lock skips the advisory check, so CI isn't blocked, but any composer update is.

config is not part of Composer's lock content hash, so the committed composer.lock stays valid unchanged.

Testing

Measured with Composer 2.10.3 on PHP 8.0.30, judging by exit code:

No other advisory ID is required.

Use of AI Tools

This PR was created by Claude Code under my supervision. All code should be treated as AI-produced and not yet reviewed by a human until this PR is marked Ready for Review.

🤖 Generated with Claude Code