Detect benchmark coverage gaps and state a verdict (#206)

[deverman]

Addresses the core of #206.

The problem, restated from evidence

Validating #88 spent four ten-minute smoke suites on a gate that never benchmarks list_projects — so none of them measured a line of the changed path. The question was ultimately answered by a ten-minute interleaved A/B. Two things were missing: knowing the suite could not measure the change, and a rule for turning numbers into a decision.

What this adds

BenchmarkCoverage maps changed files to the public tools they affect, and reports which of those the suite can actually measure. Only 3 of 9 public tools are benchmarked today, so the gap is the common case rather than an exotic one. classify now prints the assessment:

Benchmark coverage:
  ⚠️  list_projects — no benchmark in the suite
  ⚠️  list_tags — no benchmark in the suite

Benchmark coverage gap: list_projects, list_tags has no benchmark in the suite.
A passing benchmark run does not clear this change, because the suite never
exercises the path it modifies. Measure the changed tool directly with an
interleaved A/B against the baseline ref before drawing a performance conclusion.

That output is a replay against #88's real file list — the warning that would have saved four suites and about two hours.

BenchmarkVerdict turns two sample sets into an outcome plus a merge recommendation. A direction is claimed only when the change clears both a 5% relevance floor and three standard errors, so:

• a statistically clean but tiny difference reads as INDISTINGUISHABLE, not a win;
• a large difference on a noisy host reads as INCONCLUSIVE, not a regression.

Two outcomes exist specifically because of what happened during this work:

• INCONCLUSIVE — host variance swamps the effect. The 3-4x swings seen while validating Expose project folder membership and root filtering in list_projects #88 land here instead of producing a confident verdict.
• NOT COMPARABLE — the arms did not return equivalent results, so timings are meaningless. This is exactly the state Resolve multiple project or tag names in one bounded query #171 was in before its field bug was found: the fast arm was fast because it returned nothing. Without this outcome, benchmarking a broken implementation yields a beautiful, false improvement.

Tests replay the real cases

historical case	expected	result
#171 measured numbers (2402ms → 432ms)	IMPROVEMENT	✅
#88 unchanged path (385ms vs 390ms)	INDISTINGUISHABLE	✅
observed 3-4x host swings	INCONCLUSIVE	✅
pre-bugfix #171 (arms disagree)	NOT COMPARABLE	✅
2% change with near-zero variance	INDISTINGUISHABLE	✅

334 tests pass (17 new). validate --impact performance passes with all semantic gates green.

Not included

The remaining #206 scope, left for follow-up so this lands reviewable: adding actual benchmarks for the six uncovered tools, a --baseline <ref> flag that builds both refs and interleaves samples automatically, and deriving the request deadline from observed p99. This PR makes the gap visible and the verdict stated; automating the comparison is the next slice.