v0.1.3 — verify now uses the evidence next to it

Closes a gap found by an external security scan of 0.1.2. No new vulnerability — this is a case where the tool could detect tampering but did not report it.

The problem

Truncating a journal's tail leaves a perfectly valid, shorter hash chain. So aileron verify returned:

OK: 3 events verified

…even when the signed <log>.checkpoints.jsonl sitting right next to the log attested that 6 events had existed. The proof of truncation was on disk and the tool walked past it.

That matters more than the severity suggests: verify is the command in the quickstart, and the one an operator reaches for under pressure. Returning green while adjacent evidence says otherwise is the worst possible answer.

The fix

When a checkpoints file is present, aileron verify now compares event count and tip hash against every checkpoint and exits 2 on a contradiction, saying whether the journal appears truncated or rewritten:

error: log has 3 events but a checkpoint attests to 6 — the journal appears truncated
TAMPERED: chain is internally valid but contradicts run.chain.jsonl.checkpoints.jsonl
note: signatures were not checked here — run 'aileron verify-checkpoint' with the public key you trust.

aileron report applies the same check, so a truncated journal can no longer render a VERIFIED badge. Both accept --skip-checkpoint-check for deliberate log rotation.

Scope of the guarantee

The cross-check is unauthenticated by design — verify takes no key, so it compares structure rather than verifying signatures. It defeats naive truncation; an attacker who also rewrites the checkpoint file is not stopped by it. aileron verify-checkpoint with a public key you obtained out of band remains the cryptographic guarantee, and verify now points you there in its own output. SECURITY.md states the distinction plainly.

122 tests. Full detail in CHANGELOG.md.