[BUG] coding-standard: single-vendor installed_paths assumption breaks mage-os-repo projects (php-compatibility-fork lands in vendor/mage-os)

[rhoerr]

Summary

The coding-standard action's "Register Coding Standard" step assumes magento/magento-coding-standard and magento/php-compatibility-fork install into the same vendor directory. On projects using the Mage-OS composer repositories the packages split across vendors — magento-coding-standard resolves to vendor/magento/ while php-compatibility-fork resolves to vendor/mage-os/ — so the step writes a nonexistent path for the fork, the PHPCompatibility standard can't resolve, and phpcs exits 3.

This is a sibling of #213: the fix for that (#216, "probe vendor dir for phpcs installed_paths", v7.0.0) probes which vendor magento-coding-standard landed in, but then applies that single vendor to both packages:

# coding-standard/action.yml — "Register Coding Standard"
if [ -d vendor/magento/magento-coding-standard ]; then
  CODING_STANDARD_VENDOR=magento
elif [ -d vendor/mage-os/magento-coding-standard ]; then
  CODING_STANDARD_VENDOR=mage-os
fi
vendor/bin/phpcs --config-set installed_paths \
  "vendor/${CODING_STANDARD_VENDOR}/magento-coding-standard,vendor/${CODING_STANDARD_VENDOR}/php-compatibility-fork"

It also drops vendor/phpcsstandards/phpcsutils, which the dealerdirect plugin had (correctly) registered in the step before.

Reproduction

Module: mage-os/module-ai-base (composer.json declares the mirror.mage-os.org + repo.mage-os.org repositories), workflow pinned at check-extension.yaml@v8.9.0.

Failing job: https://github.com/mage-os-lab/module-ai-base/actions/runs/29464192368/job/87513783669

ERROR: Referenced sniff "PHPCompatibility.FunctionUse.RemovedFunctions" does not exist.
ERROR: Referenced sniff "PHPCompatibility" does not exist.
ERROR: Referenced sniff "PHPCompatibility.Syntax.ForbiddenCallTimePassByReference" does not exist.
ERROR: Referenced sniff "PHPCompatibility.Keywords.ForbiddenNames" does not exist.
...
Run "phpcs --help" for usage information
##[error]Process completed with exit code 3.

Resulting vendor layout on such a project (locally reproducible with composer require "magento/magento-coding-standard:*" "magento/php-compatibility-fork"):

vendor/magento/magento-coding-standard      <- present
vendor/mage-os/php-compatibility-fork      <- the fork lands here, not vendor/magento
vendor/phpcsstandards/phpcsutils

Setting installed_paths to the action's value locally reproduces the identical exit-3 failure.

Suggested fix

Either:

1. Resolve the vendor per package (probe magento-coding-standard and php-compatibility-fork independently), and include vendor/phpcsstandards/phpcsutils; or
2. Simpler: skip the "Register Coding Standard" step entirely when the dealerdirect phpcodesniffer-composer-installer plugin has already set installed_paths — its auto-registration is correct for every layout (the action already trusts it in the "no directory found" fallback branch).

Workaround

Declare the paths in the module's own ruleset — <config> in phpcs.xml.dist takes precedence over the CodeSniffer.conf value the action writes:

<config name="installed_paths" value="vendor/magento/magento-coding-standard,vendor/mage-os/php-compatibility-fork,vendor/phpcsstandards/phpcsutils"/>

That's what mage-os-lab/module-ai-base ships today; with it, the same job passes on v8.9.0.