test(parity): a divergence must fail the job, not just print

[blairham]

Found while adding a regression check for #50. This is the reason that bug shipped.

The parity suite could not fail

Every comparison is recorded with addResult and rendered into the report, but nothing ever asserts on one — no t.Error anywhere in the suite, and TestMain forces a non-zero exit only when zero checks ran. A real divergence printed [FAIL], lowered the percentage, wrote it into the JSON artifact, and exited 0.

Which makes the job description in ci.yml untrue as written:

Parity is this project's entire claim, so a change that breaks it fails before review rather than after a merge to main.

It did not. It reported.

Measured

On a tree carrying two genuine divergences (missing config made to exit 0 instead of 1):

	report	exit
before	76/78 — FAILURES: 2 checks failed	0
after	76/78 — FAILURES: 2 checks failed	1

And a clean tree is 78/78 exit 0 both ways — so this tightens the gate without moving the bar. Verified against real upstream 4.6.2 with PARITY_REQUIRE=1.

Not hypothetical

pre-commit run --files a b has been broken in every release while the headline read 78/78 (#50). The suite had no multi-path case — and even once one exists, only the filesystem assertion discriminates: both binaries exit 1, one because the hook failed and one because it could not parse. A gate that cannot fail plus a check that cannot discriminate is how a 100% parity claim and a broken common flag coexist.

docs/parity.md now says a divergence fails the run, and says plainly that this was not always true.

Verification

make check clean, make lint 0 issues, clean parity run exits 0 at 78/78.

Refs #43