[ondrejmirtes]

The phpbench job measures wall-clock time on shared GitHub runners, so its numbers move with the runner rather than with the code. It currently fails on 2.3.x itself. This PR replaces it with a Benchmarks workflow that counts executed instructions under CodSpeed's CPU simulation (Valgrind with a fixed simulated cache). The counts do not depend on the runner, so a change in them comes from the code.

How a benchmark is measured

• tests/bench/measure.php boots PHPStan in-process, analyses tests/bench/Warmup.php to load and compile the common code paths, then measures only the analysis of the benchmark file. Start/stop comes from CodSpeed's instrument-hooks library, called over FFI. Boot (about 5 G instructions) is no longer part of every number.
• tests/bench/run.php runs one benchmark. First it runs natively, with a 60 s timeout, to fill the caches in a tmpDir of its own and catch infinite loops early. Then it runs under codspeed run --mode=simulation with a 90 min timeout. It records instructions, estimated cycles (instructions + 10 × L1 misses + 100 × LL misses) and peak memory.
• tests/bench/phpstan.neon is the config the benchmarks are analysed with: level 8, bleedingEdge, inferPrivatePropertyTypeFromConstructor. tests/bench/data stays excluded from PHPStan's own analysis.

The workflow

• shard.php splits tests/bench/data into 4 shards by expected instruction count (longest first). Each shard runs its benchmarks in parallel, one per CPU.
• compare.php compares everything with tests/bench/expected.neon. A metric may differ by 5 % (10 % for memory), and by at least 25 M instructions / 35 M estimated cycles, so the quickest benchmarks, which mostly run shared code, are not held to a fraction of a millisecond. I picked that floor from measuring every benchmark under 1 G at 2.3.0, 2.3.5 and 2.3.x: files under 200 M drifted by up to 11 M between releases, while the real regressions from eea09a949/4dab5341b (40–170 M) still fail.
• Only slower and not measured benchmarks fail the job. Faster and new ones pass but ask for expected.neon to be updated, because until then a later slowdown back to the old numbers would go unnoticed.
• The report is printed in the job log and the job summary, with the full table collapsed. Each benchmark that differs is also annotated on its file in tests/bench/data. The report ends with a reproducer command and the two commands that accept the new numbers from the benchmark-measured artifact.

Numbers

• Repeated runs of all 86 benchmarks agree to within 0.07 % of instructions. The exception is literal-key-union-offset-write, which uses about 1 GB of memory and varied by 0.4 %.
• Under the simulation a benchmark takes 13 s to 8.5 min, except phpdoc-inheritance-speedup, which takes about 40 min. That file sets how long the workflow takes.
• expected.neon is measured at the current 2.3.x, so it includes Resolve names added by fixes only when a fix adds names #6967, Share the resolved class constant type between the native and PHPDoc passes when the constant has no PHPDoc type #6968, Index already normalized union members and overwrite markers instead of scanning them #6969, Avoid quadratic work when combining many same-shaped constant arrays #6970, Speed up the falsey isset() fold over many optional offsets #6971 and Describe array shapes once while sorting a union, memoize a union's loosely equal types #6973. Those fixes came out of bisecting this suite's numbers across releases.
• I generated expected.neon in Docker (Ubuntu 24.04, ondrej PHP 8.5, CodSpeed 5.6.3), not on a GitHub runner. If this PR's first run differs anyway, I'll replace the file with that run's benchmark-measured artifact.

Also in this PR

• Removed phpbench: bench.yml, phpbench.json, BenchCase, RegressionBench, the stored baseline, the Makefile targets and the dependency in tests/composer.json.
• The parser, comparator, report and sharding are pure classes covered by unit tests in tests/PHPStan/Benchmark. All I/O stays in the scripts.
• CLAUDE.md explains the benchmarks and how to analyse a file from tests/bench/data.