docs: post-release sync — compatibility matrix, and a runbook that matches reality

[bkd-dotcom]

Brings the umbrella in line with the 2026-09-01 release train: core v0.8.0,
reviewer v0.3.0, eval v0.3.0, action v0.5.0, plugins v0.3.0,
claude-code/codex/cursor/precommit v0.4.0, github-app v0.2.0.

COMPATIBILITY.md had drifted four kernel releases

It called 0.4.0 "(latest)" — the kernel is at 0.8.0, so 0.5.x, 0.6.0, 0.7.0
and 0.8.0 were missing entirely from the table people read to learn what the platform
can do. The highlights for each are taken from core's own changelog, not written from
memory.

The integration table had three separate problems:

• github-app was marked "(planned)" and has a v0.2.0 release.
• A duplicate row listed claude-code / -cursor / -codex / -precommit as "(planned)
  split from signetry-plugins" below the four rows describing the split that already
  happened.
• plugins was marked "Superseded by the per-agent repos" — it is not; it ships
  today as v0.3.0 and is the bundle for people who want all four editors at once.

It also only showed a minimum signetry-core, which answers the wrong question. Every
integration pins an exact tag, and a reader wanting to know what they get on install
could not find it. There are now two columns — Minimum and Pins — plus a Released
column, so a row whose pin lags is visible as a row to fix. That is the point of showing
it.

RELEASE.md told you to do an impossible step

• tag vX.Y.Z pushed; PyPI publish

signetry-core was removed from PyPI at 0.5.4 and has been installed from a git tag
ever since. Anyone following the runbook would look for a publish step that cannot
happen. It now says what actually happens (release.yml cuts the Release and attaches
the wheel) and why there is no PyPI step.

Three checklist items are added, each one a defect this release train actually hit:

• sweep install.sh's default VERSION — it had drifted to 0.6.0, two releases
  behind, while the comment above it promised "the latest hardened tag". It escaped
  every pin sweep because the version and the URL are on separate lines.
• repoint each moving @vN tag — reviewer@v1 was ten commits and two minor
  releases stale, predating the rename, while the landing page advertises @v1 as the
  way to consume it. @vN is validated for existence, never against the newest tag,
  so one that stops moving cannot be detected as stale.
• run the site's check_versions.py — the landing page's install command is a
  hand-maintained claim, and a visitor who copies a stale pin installs a release behind.

Pins

core@v0.7.0 → core@v0.8.0 in INSTALL.md, INTEGRATIONS.md, LAUNCH.md, and the
@v0.3.0 exact-tag example in RELEASE.md → @v0.5.0, the action's actual release.

[github-actions]

Signetry Reviewer — 🟡 Needs human review

A human should decide — the required check is unknown.

Deterministic gates (the authority)

Gate	Status
Required status check	— unknown
Secret scan	✅ clean
CI permission / OIDC	✅ no forbidden change
Dependency skew	✅ ok
All green	❌

Findings

No issues found by the deterministic scanners.

Merge

A human should review and merge.

This review is advisory. It never merges on its own judgement — the deterministic gates + a human are the authority. Findings can have false negatives; a green bot verdict is not a guarantee.