Simplify and strengthen the test and quality stack

[vitormattos]

Context

A final architecture/CI audit found that the project has broad tooling coverage, but some checks are redundant or configured too weakly to justify their CI cost.

Findings

Mutation testing

docs/testing.md calls Infection a quality gate, but the Composer script currently passes --min-msi=0 --min-covered-msi=0. The latest successful run reported:

• Mutation Code Coverage: 100%
• Covered Code MSI: 78%
• 2011 mutants killed
• 568 covered mutants escaped

Make the threshold real and improve escaped mutants incrementally rather than running Infection as an informational-only job.

Static analysis

Current configuration is intentionally/accidentally lenient:

• PHPStan level 5, while current PHPStan supports levels 0–10;
• Psalm errorLevel 4, while Psalm level 1 is strictest;
• both analyze only src, not project test/support PHP.

Evaluate raising strictness first, then decide whether both analyzers still produce materially distinct value. Do not keep two low-signal analyzers simply for tool count.

Style / maintainability overlap

• PHPCS currently enforces only PSR-1.
• PHP-CS-Fixer currently enforces only declare_strict_types and ordered imports.
• PHPMD currently runs only unusedcode.xml.
• Rector is also present.

This is too fragmented for the amount of policy each tool enforces. Prefer one explicit coding-style source of truth and remove checks that become redundant after static-analysis strictness is raised.

PHAR acceptance coverage

tools/test-phar.php and tools/test-publication-phar.php contain more than 20 KB of hand-rolled test harness code outside PHPUnit. They duplicate fixture/server/process infrastructure already present in the PHPUnit integration/acceptance suite and produce poorer failure reporting.

Move PHAR/source parity scenarios into PHPUnit acceptance tests and reusable test-support helpers, then delete the standalone scripts.

CI structure

php-quality.yml uses an 8-entry matrix where every entry checks out the repository, sets up PHP and performs a full Composer install. Revisit grouping after tool consolidation so CI does not pay eight dependency-install costs for a small CLI project.

Keep separate jobs only where isolation/parallelism materially improves signal or execution time.

Tools not to add

Do not add phpcpd: the upstream project is archived/read-only. Duplication should be addressed through design/static analysis/refactoring rather than adding an abandoned dependency.

Desired outcome

• meaningful mutation threshold;
• stricter type analysis with less duplication;
• one clear coding-style policy;
• PHAR acceptance scenarios integrated into PHPUnit;
• fewer redundant Composer-install jobs;
• no reduction in security checks (Composer audit, actionlint, zizmor, REUSE, PHAR reproducibility).

[vitormattos]

Additional workflow finding:

• zizmorcore/zizmor-action is SHA-pinned, which is good, but its version input is omitted. In v0.6.2 that input defaults to latest; the latest CI run therefore downloaded/executed zizmor v1.29.0 dynamically. This makes a security gate non-reproducible even though the Action wrapper itself is pinned.
• Pin an explicit zizmor tool version (or adopt an equivalently reproducible installation strategy) and update it deliberately.
• actionlint is currently v1.7.12, which is the current upstream release, so there is no immediate version gap there; its hard-coded Go-install version is simply not Dependabot-managed.

This should be handled as part of workflow simplification/reproducibility, not by adding another scanner.