fix: respawn on same-file reflection staleness and post-boot classes

[fdaviddpt]

What broke

Two ways a warm worker served answers that disagreed with a cold phpstan run on the same file. Both were found from the consumer side — the validator kept reporting errors I had just fixed, and a fresh run said PASS.

1. Same-file reflection staleness. 0.6.0 deliberately excluded the analysis target from the staleness check:

The target itself is excluded (phpstan re-reads the analysed file's own AST each call)

That is true of the AST and false of the reflection. After editing a class-level @extends generic, the worker kept resolving $this->options against the shape captured at first analysis — so a correct fix kept reporting the error it had just fixed. The symmetric case is worse and silent: a newly introduced shape error would not be reported at all.

2. Classes created after boot are invisible. The worker's analysable file set is fixed at boot, so a class added afterwards reads as extends unknown class Foo for a file sitting on disk that a cold run resolves fine — with phantom errors at stale line numbers on top.

The fix

Structural fingerprint for the target. Declarations, signatures, property types and docblocks, with function bodies stripped (token_get_all, skipping from a function's { to its matching }). A changed fingerprint respawns the worker. A body edit leaves it identical, so the edit-check-edit loop on one file stays warm — which is the whole point of the package.

One respawn on class.notFound. Content alone cannot distinguish "created after boot" from "genuinely missing", so pay one respawn and report the fresh worker's verdict. Bounded to a single retry per call.

MCP_PHPSTAN_PHPSTAN_BIN. Found while building the harness, and a real bug on its own: findPhpstanBin() resolved phpstan from the server's vendor directory, so a global install analyses a project with the wrong phpstan — none of the project's extensions or custom rules, far fewer errors, no complaint.

Evidence

Against a real project (~14k PHP files), same config and paths, one warm server per run:

Scenario	0.6.0	this branch
Class created after boot	class.notFound ×2 + phantom return.missing	clean
Genuine shape mismatch	(masked by the above)	offsetAccess.notFound — still caught
After fixing the @extends generic	same errors, repeated	clean

Warm-path cost, measured on the same server:

[cold]        first analyse :   6.4s
[warm]  body edit #1 analyse:   0.0s
[warm]  body edit #2 analyse:   0.0s
[warm]  body edit #3 analyse:   0.0s
[respawn] signature change  :   6.1s

A note on the harness. Its first version reported CLEAN for every scenario, which looked like a total fix. It was a broken harness: the dev-repo server resolved its own phpstan, which loads none of the project's extensions, so it analysed almost nothing. A control case — a blatant return 42; in a : string method — caught it. That control is why MCP_PHPSTAN_PHPSTAN_BIN exists in this PR, and it is worth keeping in mind for any future benchmark here: a warm-process server that quietly does less work looks exactly like a fast one.

Tests

11 new unit cases in PhpstanRunnerStalenessTest — body-only edits keep the fingerprint stable; class-level generics, method signatures and property types change it; formatting and line comments do not; a bodyless abstract method does not derail the token scan; plus the binary-override contract. Full suite 25/25, including the 0.6.0 cross-file regression test.