fix(cpg): prove the frontend can read the source before building, and check the graph always

Two permanent guards, and a correction that motivates both.

THE CORRECTION. There is no php2cpg defect. Every PHP build on this machine
ran through a local `php` shim proxying stdio through `docker run`, and
php2cpg depends on the INTERLEAVING of its parser's stderr banners with its
stdout JSON to attribute each document to a file. The proxy scrambles it:

    streaming shim   drops 72-88   767KB / 969KB / 1.2MB   different every run
    buffered shim    drops 0       5,703 bytes             empty, and silent
    NATIVE php       drops 0       2,872,996 bytes         identical x3

The 637-file tree with native php: 0 drops, a 4,329,471-byte CPG, 20.0s,
1.9GB peak -- which is exactly what task 5.10 said before I started
"correcting" it. No intermittent failures, no malformed graph, no dataflow
assertion, no scale limit.

GUARD 1: the interpreter must prove it can read the tree, before anything is
built. Every instrument failure this project has had takes one shape -- the
input was unreadable and the tool reported a plausible ZERO -- and it has cost
four wrong diagnoses in a day:

    a php that could not see ~/.cache   -> "cannot handle 637 files"
    a php whose stdio was proxied       -> "drops half its batches"
    a container missing a bind mount    -> "0 dropped", 5,703-byte graph

None announce themselves: file_exists() is false, the parser writes nothing,
the frontend exits 0, and "no errors" reads exactly like success. Checking the
output cannot separate that from an empty repository. Checking that the input
arrived can, and costs one exec.

GUARD 2: the graph census is taken on EVERY build, not only one the frontend
warned about. A graph holding nothing arrives with no warnings at all --
silence is the symptom that has no symptom -- and the shortfall is now
reported as "the frontend reported no failures but the graph holds N of M
source files".

`cpg_build_failed` carries that detail through to the report instead of being
a bare reason.

Also adds tests/test_cpg_queries_compile.py: the queries are 900 lines of
Scala that nothing compiled. A rowsFor signature change shipped with 850 tests
passing and broke every query at runtime, found by a measurement failing hours
later. Each query is now compiled AND run against a real graph wherever joern
exists, and must return a parseable payload.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG

benchmarks/repos/README.md

@@ -218,6 +218,15 @@ obvious question is whether any of it survives on the whole plugin. Measured on
 The build is affordable; a CI runner can do this without a vertical-scale machine, which was the open
 question. The scan is not.
 
+**Correction, and it invalidates the paragraph below.** Every PHP build behind these numbers ran through a
+local `php` shim that proxies stdio through `docker run`, and php2cpg depends on the interleaving of its
+parser's stderr banners with its stdout JSON to attribute documents to files. The proxy scrambles that
+ordering: 72–88 dropped files per build, a different graph every run, and a corrupted CPG that makes Joern's
+dataflow overlay assert. With a **native** php the same 637-file tree builds in **20.0s** to a
+**4,329,471-byte CPG** with **zero** drops, byte-identical across runs. There is no frontend defect, no scale
+limit, and the whole-repository scan has never actually been measured here. What follows is kept as the
+record of a wrong diagnosis, not as a result.
+
 It is worth being precise about *why*, because the obvious answers are all wrong. It is not memory: at 2 GB
 and at 4 GB the CPG never finishes loading, with no `OutOfMemoryError` in either case, both runs stopping in
 the same place — `Braintree\Util`. It is not the request payload either. What costs is Joern's dataflow