chore: normalize Actions cache keys

[paulbalandan]

Description
The Actions cache list grows by dozens of entries after a few hours of activity. Two key designs cause it:

1. The composer download cache uses seven different key schemes across the workflows. The PHPUnit reusable includes the job id and DB platform in the key, so one composer.json change saves the same 46 MB directory about 30 times per branch. The coding standards and Psalm keys hash the gitignored composer.lock, which produces an empty hash (the key was literally Linux-8.2-).
2. The PHPStan, Psalm, Rector and Structarmed result caches are keyed on github.sha or github.run_id, so every push and every re-run saves a new entry, including sync merges and docs-only commits.

This PR normalizes the keys:

• Every composer cache uses composer-php-<version>-<hash of composer.json> with restore keys composer-php-<version>- and composer-. The job id and DB platform are dropped, since they never affect the download directory.
• The four analysis caches are keyed on a hash of the analyzed sources (**/*.php, their config and baseline files, and composer.json). An identical tree hits the exact key and saves nothing. A code change falls back to the newest prefix match and saves a fresh entry, so incremental analysis keeps working. The Rector and Structarmed cache steps move above composer update so the glob is evaluated before vendor/ exists, as PHPStan and Psalm already do.
• runner.os is removed from all keys. Every key is now tool-named.

Existing entries under the old key shapes become orphans until eviction. The first run per branch after merge will miss and repopulate.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide