release(0.5.0): the assessment axis ships, and every version surface moves with it

0.5.0 is the axis separation `de09711` built: `Risk` (assessment) alongside
`Disposition` (action), `Policy.action_map` as the supported override, and the
fail-closed path pinned to both axes. Additive and measured to be so — 717
passing with no test changed, matrix 128/128 with 6/6 documented gaps, the
`PRESET_USER_UPLOAD` grading table unchanged row by row. Plus the field FP
measurement (`d1bff60`) and the 0.3.3 behaviour-change correction (`d3d0928`).

WHY THIS COMMIT TOUCHES EIGHT FILES AND 0.4.0's TOUCHED THREE

0.4.0's release commit updated CHANGELOG, pyproject.toml and __init__.py, and
deferred README deliberately: the install block should not name a tag before a
clean-venv install had proven it resolved. Sound reasoning, and the proof step
never ran — so tag v0.4.0 permanently advertises v0.3.4. The tag is not moved.
The ordering is.

Sweeping every tracked file for a version claim, instead of ticking the four
surfaces the checklist named, found five more that no release had ever touched:

  SECURITY.md          "pre-1.0 (0.2.x)" — the one with a consequence for an
                       outsider: it named a support window two minor lines
                       behind the code.
  README.md            "**Status:** v0.3" — the front page, stale since 0.4.0.
  docs/BRIEF.md        "v0.2 (alpha)" — stale since 0.3.0.
  CLAUDE.md            "v0.2 (alpha)" and "12 moduler" where src/ has 15.
  docs/ADOPTION-BRIEF  "703 passing" where the suite is at 717.

Measurement provenance is deliberately left alone: "New in v0.4.0", "verified
identical on 0.2.0 and 0.3.1", "measured against the v0.3.1 tag", every
"post-0.4.0 tree" in LIMITATIONS. Bumping those falsifies the record instead of
updating it, which is why this cannot be a sed sweep — the surfaces have to be
sorted into current-state and provenance before a single edit.

Found because llm-ingestion-okf took our report of this defect class as a
hypothesis about their own repo, measured it, found a worse instance on their
public front page, and sent back the generalization: writing down a trap is not
the same as applying it.

VERIFIED BEFORE COMMITTING, NOT AFTER

  717 passed; coverage 128/128 recall, 6/6 documented gaps hold
  docs/LIMITATIONS.md: 33 items, README says 33
  fp-sweep reproduced all three published numbers exactly on the bumped tree —
    vendor-harvest 98/185 (53.0%), generated-notes 88/547 (16.1%),
    reference-corpus 133/389 (34.2%) — and self-docs runs clean, so the
    untested script survived the bump it imports names from
  forge description: 178 codepoints, under the 180 cap
  no tracked file carries a stale current-state version claim

Still to prove before the tag: a clean-venv install from this commit's sha, and
`git show <sha>` over the README. The install proves the package builds; only
the grep proves the text the tag will carry is right. That second check is the
one the old ordering could not perform, because by then the tag existed.

CHANGELOG.md

@@ -7,6 +7,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+Nothing yet.
+
+
+## [0.5.0] — 2026-08-11
+
 ### Added — the axis separation: assessment (`Risk`) vs action (`Disposition`)
 
 > **Additive, and measured to be so.** Every disposition 0.4.0 rendered is
@@ -117,6 +122,37 @@ none, and it took a field sweep to find it.
   the comment was not. Corrected, with the retraction written into the comment so
   it cannot read as a second, disagreeing measurement.
 
+- **Five current-state version claims had never been updated by any release.**
+  The 0.4.0 release commit touched three files — `CHANGELOG.md`,
+  `pyproject.toml`, `src/llm_ingestion_guard/__init__.py` — and deferred the
+  README deliberately, so that the install block would not point at a tag before
+  a clean-venv install had proven it resolved. That proof step never ran, so tag
+  `v0.4.0` permanently carries a README advertising `v0.3.4`. The tag is not
+  moved; the ordering is.
+
+  Sweeping *every* tracked file for a version claim, rather than the four
+  surfaces the release checklist named, found four more that no release had ever
+  touched — plus a stale test count:
+
+  - `SECURITY.md` — "The project is pre-1.0 (`0.2.x`, alpha). Only the latest
+    published version receives fixes." The only one with a consequence for an
+    outsider: it named a support window two minor lines behind the code.
+  - `README.md` — `**Status:** v0.3`, stale since 0.4.0.
+  - `docs/BRIEF.md` and `CLAUDE.md` — "v0.2 (alpha)", stale since 0.3.0. The
+    latter also claimed 12 modules where `src/` has 15.
+  - `docs/ADOPTION-BRIEF.md` — "**703 passing**", where the suite is at 717.
+
+  Every one of them is a *current-state* claim. Measurement provenance — "New in
+  `v0.4.0`", "verified identical on 0.2.0 and 0.3.1", "measured against the
+  v0.3.1 tag" — is left exactly as written, because bumping those would falsify
+  the record rather than update it. From here all current-state surfaces move in
+  the release commit itself and are verified by `git show <sha>` *before* the tag
+  exists, since that is the only check the previous ordering could not perform.
+
+  Found because `llm-ingestion-okf` took our report of this defect class as a
+  hypothesis about their own repo, measured it, found a worse instance, and sent
+  back the generalization: writing down a trap is not the same as applying it.
+
 
 ## [0.4.0] — 2026-08-10