chore(release): adopt rivet v0.22.0 release-handling as the readiness gate

[avrabe]

What

Adopts rivet v0.22.0's release-handling for meld's release process, and tests it.

rivet v0.22.0 (rivet release status <ver>) turns the release: field into a queryable readiness gate: per-status burn-down, a cuttable verdict, non-zero exit when not cuttable (CI-gateable), and --format json.

Changes

• Bump the compliance.yml rivet pin v0.19.0 → v0.22.0.
• Scope SR-45 (the v0.37.0-delivered fusion-premise requirement) with the first-class release: v0.37.0 field (via rivet release move), and move it implemented → verified — its V is closed (SWV-45's SCPV v3 codec + golden-fusion tests pass), matching the existing 28-verified convention.
• Document the release-readiness query as a mandatory pre-release checklist step in AGENTS.md.

Tested

$ rivet release status v0.37.0
Release v0.37.0 — 1 artifact(s)
  verified     1
✓ Cuttable — every artifact is verified/accepted.          # exit 0

$ rivet release status v0.37.0 --format json
{ "cuttable": true, "not_verified": [], "by_status": {"verified": 1}, "total": 1, "release": "v0.37.0" }

$ rivet validate   →  PASS (70 pre-existing warnings)

Notes / scope

• Historical per-release vX.Y tags on artifacts are "shipped-in" markers and stay; the release: field is the single forward scope rivet release status reads (many SRs are multi-tagged across releases, so they can't map 1:1 to a single release:). This PR establishes the mechanism on v0.37.0 as the demonstrator; scoping additional releases' artifacts is incremental follow-up before rivet release status becomes a hard CI gate.
• Advances Release standard: add witness + scry wasm gates, crates.io/npm, rivet verification extraction #302 Track E (rivet verification/release gating).

Config + safety-YAML + docs only — no code touched.

🤖 Generated with Claude Code

[github-actions]

LS-N verification gate

✅ 58/58 approved LS entries verified

	count
Passed (≥1 test, all green)	58
Failed (≥1 test failure)	0
Missing (no ls_*_NN_* test found)	0

_{Approved loss-scenarios.yaml entries are expected to have a
regression test named ls_<letter>_<num>_* (e.g. LS-A-11 →
ls_a_11_*). The gate runs each prefix via cargo test --lib --no-fail-fast and aggregates pass/fail/missing.}

Failed LS entries

(none)

Missing regression tests

(none)

_{Updated automatically by tools/post_verification_comment.py.
Source of truth: safety/stpa/loss-scenarios.yaml.}