`verify` reports an old report as a hash mismatch, which reads as tampering

[Bubblegunn]

A report carries the tool version that produced it (version) and a schemaVersion. verify recomputes the canonical hash and, on a difference, says only:

hash mismatch: report says <a>, computed <b>

Twice already the hash has deliberately changed what it covers. 0.3.0 moved cadence to the author's own weeks; 0.4.0 removed the local directory name and the git version string, because they belonged to the machine rather than the repository. Both CHANGELOG entries tell readers to regenerate. Nothing in verify does.

So somebody handed a report generated a few weeks ago runs verify and is told the hash does not match. For a tool whose entire purpose is trust, that message points at the wrong conclusion. The natural reading of a hash mismatch is that the document was edited. The real cause may be that the sender simply used an older release.

Done when

• verify compares the report's version and schemaVersion against what this build produces, and when they differ it says so first, before or instead of the bare mismatch, naming both versions.
• The message distinguishes the two cases in plain words: this report was produced by a version whose hash covered different fields, so regenerate it; versus this report's hash does not match its own contents under its own version, which is the case that should alarm you.
• The exit code still fails. This is about what the human reads, not about accepting a report we cannot verify.
• A test pins both paths, using a fixture report from an older schema. Committing that fixture is part of the work and is the reason this issue is not a one-liner.
• The README's verify section says what a version difference means, since the person reading it may be a hiring manager rather than an engineer.

Out of scope. Verifying old formats, or any compatibility shim. We are not promising to check a 0.3 report; we are promising not to imply someone forged it.

A question worth settling in this issue first. Should verify refuse outright on a version it cannot reproduce, or attempt the check and explain? Say what you think before writing code.

---

Taking this on: comment and it is yours, so two people do not write the same patch. No design document needed unless the issue asks for one.

What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat. CONTRIBUTING.md has the rest.