Evidence Agent: read-only evidence planning against the tool registry

[SurefireStudios]

The read-only evidence tool registry exists in every fixture, but verification currently reads the trajectory and both snapshots directly. That was the right call for the benchmark (an agent that plans evidence queries adds cost without adding measured value there), but real systems will not hand over a full final-state snapshot.

Proposal

An Evidence Agent that takes the compiled contract and produces a minimal plan of validated read-only tool calls, executes them, and emits evidence records linked to requirement ids, with explicit missing and contradictory evidence markers.

Non-negotiable

It must never invoke a write-capable tool, and the boundary is enforced in code and covered by a test, not by convention.

[SurefireStudios]

Follow-on: read-only evidence adapters for real systems

Folded in from #8, which was closed because it opened by depending on this issue and could not be started independently. Keeping them as two items made one undesigned thing read as two.

Once an evidence-source interface exists here, adapters can sit behind it.

Candidates: a payment provider in test mode, a ticketing API, a database via a read-only role. Each adapter exposes only reads, with the guarantee enforced at the integration boundary (scoped credentials, allow-listed endpoints), and each evidence record carries the provenance of where it came from.

Not in scope: any autonomous write, approval or execution. StateProof verifies; a qualified human decides.

That last constraint is really a constraint on this issue's design too: whatever interface the Evidence Agent plans against has to make a write unrepresentable rather than merely discouraged, or every adapter written later inherits the weaker guarantee.