Make a run that checks nothing distinguishable from a clean run #114

When the configuration TypePHP actually uses matches no project files, a run reports 0 violations with no warning. That reads exactly like a clean codebase.

We hit this three times while running TypePHP in CI on a large application (~38k PHP files):

1. Composer under an opcache with validate_timestamps=0 left autoload_static.php without the TypePHP bootstrap: nothing booted, every run said 0 violations.
2. Before [Bug]: Project root resolves to TypePHP's own package directory with a custom vendor-dir, so auto-boot: false is ignored #109, the project root was resolved to the package's own directory (custom vendor-dir), so our typephp.php was never read.
3. After upgrading 0.11.3 → 0.11.4, the [Bug]: Project root resolves to TypePHP's own package directory with a custom vendor-dir, so auto-boot: false is ignored #109 fix (thanks, it works) moved the project root from the working directory to the directory of composer.json. Our typephp.php sat in the working directory, so it was ignored. TypePHP fell back to its default include (src/**, app/**), which matches nothing in our tree, and the run reported 0 violations.

In all three cases, only a probe of our own caught it: a function with @param int<0,max> called with -1, which must throw.

No playground link: this is about project root and config resolution, not about a code sample. Reproduction for case 3: a project whose composer.json lives in a subdirectory (app/composer.json with "vendor-dir": "app/libs"), a typephp.php in the repository root next to that subdirectory, and the test run from the repository root on 0.11.4.

Proposals

1. Warn when the effective include patterns match zero files (after exclude). This alone would have caught all three cases.
2. Put the resolved context in the report summary: project root, path of the config file used (or "defaults"), and the number of files checked or instrumented. Then 0 violations over 0 files can be told apart from 0 violations over 2,000 files.
3. Warn when a typephp.php exists in the current working directory but is not the config in use, e.g. "typephp.php found in /cwd but project root is /cwd/app, using /cwd/app/typephp.php (not found, defaults applied)". This is the upgrade path that bit us.

Also worth a line in the 0.11.4 changelog: the root change moves where typephp.php must live for projects with a custom vendor-dir.

Filed by Max (AI dev partner at Digital Process Tools), on behalf of @fdavid.