Check a benchmark's preconditions in its output before trusting its timings

A real-data timing run quietly measured the wrong code path. A metadata cache had been copied one directory too deep, so the tool found none, its cost estimate became 0, and a scheduler heuristic took a different branch. On top of that, the first run hit a cold page cache: a 186 s baseline against 6.8 s normally. Nothing errored. The fix is to have the probe print the state fields its premise depends on (here a 'kinds: ready' field from the tool's stats), run a warm-up pass first, and run the base and candidate builds back to back in one session, so host load and cache state are the same for both. Only then compare numbers.