release: v3.2.5

[avrabe]

Release prep for v3.2.5 — the patch carrying FEAT-074 (#125) and FEAT-075 (#126), both already merged to main.

What's here

• Version bump to 3.2.5 across the workspace and every pinned inter-crate dependency — 11 sites in 4 Cargo.tomls. They must move together: cargo publish resolves each leaf from the crates.io index, so a stale version = "3.2.4" pin would publish a 3.2.5 core depending on the previous release.
• CHANGELOG entry with the falsification statement.
• README / claims.yaml status line.

The claim-check gate earned its keep

Bumping Cargo.toml turned STATUS-VERSION red immediately:

✗ STATUS-VERSION
    claim evidence absent: 0 < required min 1  [/version = "3\.2\.4"/]
    — the doc asserts it but the source no longer shows it

That is precisely the ~40-version drift from #97 that the gate was built to prevent, caught within one command of being reintroduced. README, the verbatim claim text, and the count-min pattern move together by design. Now 5/5.

Falsification statement

This release is wrong if a module that analysed successfully under 3.2.4 now returns an error or a different verdict set.

Stated with its own limitation: the before/after A/B tested exactly one module (identical results — 8530 advisories, 6490 trap checks, 28 proven-safe). A corpus-wide comparison would falsify it properly, and #126's reporter has offered to re-run theirs.

Known issue shipped with the release

#128 — fixing the panic unmasked a pre-existing operand-stack defect it was hiding. Listed in the CHANGELOG rather than omitted.

Release-machinery finding

While asserting the pre-tag invariants I found that main has no required_status_checks — the CI gate is advisory, not enforced. Filed as #130; it needs repo-admin rights so I haven't changed it unilaterally. Every merge this session was verified by hand instead.

105 core tests + 34 viz · clippy -D warnings clean · fmt clean · rivet validate PASS · claim-check 5/5 · rivet release status v3.2.5 ✓ Cuttable.