docs: say what is proven, not what is implemented

[blairham]

Launch-readiness docs, in the shape stevedore used — with the difference that this project is a port, so every claim gets read by someone who already uses the original.

The claim that needed grading

The README advertises "22 supported languages". All 22 are registered, so it is not false — but ten of them (conda, coursier, dart, dotnet, haskell, julia, lua, perl, r, swift) live in a single others.go with no test file, and the parity suite's own configs only ever use language: system and language: python. A reader takes "supported" to mean "someone has run this".

docs/parity.md grades each language by the evidence that exists — differential vs Python / unit tests / exercised in CI — and says the untested rows are untested, which is a different and more defensible claim than "broken" or "supported".

Behaviors documented rather than changed

Per the decisions on #43, the binary keeps its name and the cache stays shared. Both are now stated in the README's install section and in docs/parity.md, with the mechanics verified rather than assumed:

• Two tools against one store coexist — db.db and db.json side by side, repo3_4fef0c next to repocf9afd75442a4da1, and they interlock correctly because both take an exclusive flock on the same .lock.
• pre-commit clean does remove Python's environments along with its own; Python's next run rebuilds ([INFO] This may take a few minutes...).

Docs added

File	Job
docs/parity.md	What is measured (78/78 vs Python 4.6.2), what is not, the language grading, platform reality (ubuntu-latest only; Windows never run), and the surprising-but-deliberate behaviors
docs/comparison.md	Leads with reasons to keep using Python pre-commit. Also states what this is not: not a fork, not affiliated, not faster at running your actual hooks
docs/stability.md	v4.6.6 means parity with upstream 4.6 — not four majors of maturity. What is frozen, what is not, and what the exit looks like if this stops being maintained

One broken path fixed

The README's Action example pinned @main — consumers tracking an unreleased branch. It now says @v4, which did not exist, so:

• the release workflow moves the v4 alias to each new release;
• its tag trigger narrows from v* to v[0-9]+.[0-9]+.[0-9]+*, since matching v* would make each alias update trigger a duplicate release of itself.

The v4 tag itself has to be created once, after this merges, at a commit carrying the narrowed trigger — otherwise pushing it fires a release named v4.

make test and make lint clean.

Refs #43