Define the assurance boundary for trust-critical gauntlet tooling #13

The gauntlet applies its two strongest layers to src/ratelimiter only:

That boundary — "src is the subject, tools is the instrument" — was coherent
while tools/ held only the harness. It is less coherent now that
tools/source_state.py is what certifies every other number in evidence.md.
A silent fault there does not fail a layer; it mislabels the evidence that all
the layers report into. REVISION 6 is one instance: a real provenance defect
that shipped, ran green in CI twice, and was found by hand rather than by a
layer.

The mutation layer exists because tests that assert nothing still pass. The
REVISION 5 source-state controls were exactly that shape — three asserted only
a non-zero exit, and the wrapper returns the same status when the
implementation is missing entirely. They were repaired by review, which is the
mechanism this project is trying to make unnecessary.

This issue is to decide the boundary, not to widen it. Specifically not
proposing "100% coverage for everything under tools/": most of that code is
scaffolding where the cost is real and the payoff is not.

Worth deciding:

• Which tools/ paths are load-bearing for the evidence — source_state.py is
  the clear candidate; mutants.py and must_not_match.sh are arguable, since
  each already carries its own negative control or self-test.
• Whether targeted mutants are worth writing for those paths, and which ones
  would have caught a defect that actually occurred, rather than mutants chosen
  because they are easy to generate.
• Whether mutants.py should support more than one target at all, given
  TARGET is currently a single module-level constant.
• Whether the coverage gate should extend, or whether the negative controls are
  the right instrument for tooling and coverage is the wrong one.

Deferred deliberately from the REVISION 6 repair (#12 follow-up) so a boundary
decision is made on its own rather than carried along by a technical fix.