Add tamper-evident evidence ledger and verification command

[SSBrouhard]

Goal

Make VMGA evidence tamper-evident under an explicit trust boundary suitable for demos, pilot review, and production-alpha release evidence.

Threat model and claim boundary

VMGA evidence should make post-hoc modification, reordering, truncation, or deletion of evidence records detectable during verification. This is tamper-evident detection, not tamper-proof prevention. VMGA cannot prevent a writer with filesystem access from altering bytes; it can only make alteration detectable under a stated boundary.

Hash-chaining records only detects edits by an actor who cannot recompute a self-consistent chain. An actor who can both rewrite the ledger and read the chaining key can forge a clean chain. Therefore, hard tamper-evidence claims are valid only when the chain's integrity anchor lives outside the agent or broker writer authority domain.

Acceptable anchor tiers:

1. Keyed HMAC chain: each record has a MAC keyed with a secret the evidence writer/agent cannot read. This is the realistic production-alpha default and should be preferred for v0.3.0.
2. Signed checkpoints: periodic chain-head signatures from a key held by an operator process outside the broker authority context.
3. External anchoring: chain heads written to an append-only/WORM sink or external timestamping service the writer cannot rewrite.

Without an out-of-domain anchor, VMGA evidence remains append-only JSONL and integrity-advisory. README/spec/evidence docs must keep the v0.2.1 boundary language until the anchor mechanism is implemented and documented.

Non-goals

• Do not claim tamper-proof storage.
• Do not claim confidentiality; evidence may still contain redacted-but-sensitive metadata.
• Do not claim evidence destruction prevention; gaps should be detectable, not impossible.
• Do not claim non-repudiation or compliance-grade audit by default.
• Do not protect against an attacker who controls both the writer and the anchor key; that deployment is advisory.

Acceptance criteria

• Chosen anchor mechanism is documented with its trust assumptions; v0.3.0 should default to tier 1 unless a stronger anchor is explicitly chosen.
• Ledger records commit to previous record digest and current record payload.
• Integrity anchor is stored or derived outside the agent/broker writer authority domain for hard tamper-evidence claims.
• Verification command detects and tests: mutated fields, inserted records, deleted records, reordered records, tail truncation, and forked/rewritten chains with stale or absent anchors.
• Verification fails closed: unverifiable or anchor-missing ledgers are invalid, not "no evidence of tampering".
• Ledger write failure continues to deny kinetic execution where evidence is required.
• README/spec/evidence docs state the boundary; no unqualified "tamper-proof" or "hash-chained" language.
• Advisory-mode wording is retained for deployments without an out-of-domain anchor.