feat(engine): RELEASE-CURRENT — the version page a stranger actually reads

A release is not a ref, so `git ls-remote` cannot answer this one. It is
therefore the third API call per invocation, and the only new one the
acquisition model adds.

Both sides come from the forge, never the clone: comparing a local tag to a
published release would report portfolio-optimiser as stale when the real
defect is a tag that was never pushed — REMOTE-SYNC's subject, not this one.

Measured across all 22 registered repos before the rule was locked: 4 have no
tags, 2 tag without ever publishing a release, 11 are current, 5 lag. Those 2
are why zero releases is an OK and not a finding — nothing in a repo says which
of the two legitimate conventions it follows, the same measurement that
rejected VERSION-DRIFT. Lagging is a WARN because the remedy is safe, and
because this repo is the org's worst offender: an ERROR would have let the gate
settle an operator question by exiting 1 on its own author.

The shell that produced that baseline sorted tags lexically and put v0.9.0
above v0.10.0 — the exact defect compareTags exists to fix, reproduced in the
tool meant to validate it. Recorded as an invariant: derive "newest" with the
engine's own comparator or the measurement is fiction.

CLAUDE.md's API-call count moves from two to three in this same commit; that
line has now gone stale twice. The unmarked "429 at ~40" figure is marked
unusable — its endpoint class was never recorded, and org-ops measured ~110
raw reads at 0.4s with zero 429 the same day.

205 tests (was 196).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WWc4piM4QW6Jxfky2Rw4Z8

CHANGELOG.md

@@ -4,6 +4,60 @@ All notable changes to this project are documented here.
 Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/);
 versioning is [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Added
+
+- **`RELEASE-CURRENT` — does the release page show the version the code is on?**
+  A stranger who wants a version they can name lands on the forge's release
+  page, and it is the one surface refs cannot answer: a release is not a ref, so
+  `git ls-remote` has nothing to report. This is therefore the third API call
+  per invocation, and the only new one the acquisition model adds.
+
+  Both sides are read from the FORGE, never from the clone. Comparing a local
+  tag against a published release would report `portfolio-optimiser` as having a
+  stale release when the actual defect is a tag that was never pushed (v1.0.0
+  local, v0.1.0 published) — a different finding, owned by a different check.
+
+  Four outcomes, and three of them are `OK`:
+
+  | outcome | level | code |
+  |---|---|---|
+  | releases or refs unreadable | `SKIP`/`notRun` | `RELEASE-UNAVAILABLE` |
+  | no tags on the forge | `OK` | `RELEASE-NONE` |
+  | tags, no release published | `OK` | `RELEASE-TAGS-ONLY` |
+  | newest release is the newest tag | `OK` | `RELEASE-CURRENT` |
+  | newest release lags the newest tag | `WARN`/`weakening` | `RELEASE-STALE` |
+
+  The levels come from a measurement across all 22 registered repos
+  (2026-08-12): 4 have no tags, 2 tag without ever publishing a release, 11 are
+  current, 5 lag. Those 2 — `ktg-plugin-marketplace` and `llm-security-commons`
+  — are why zero releases is an `OK` and not a finding. Nothing in a repository
+  says which of the two legitimate conventions it follows, and a gate that fails
+  a correct repository is the mechanism that gets gates switched off. That is
+  the same measurement that rejected `VERSION-DRIFT` one check over.
+
+  Lagging is a `WARN` rather than an `ERROR` for two reasons. The remedy is
+  safe: publishing a release for a tag that already exists moves no published
+  ref, unlike the remedy `TAG-ANNOTATED` has to withhold from tag history. And
+  this repository is the worst offender in the org — v0.9.0 tagged, v0.3.0
+  published — so an `ERROR` would have let the gate settle an operator
+  question, whether this org publishes releases at all, by exiting 1 on its own
+  author.
+
+### Changed
+
+- **The API-call count in `CLAUDE.md` is three, updated in the same commit as
+  the check that changed it.** That line has now gone stale twice; the first
+  time it stayed stale until a 13-repo shell loop trusted it and tripped the
+  rate limiter.
+- **The "429 at ~40 requests" figure is marked unusable.** The run that produced
+  it did not record which endpoint class it hit, and org-ops measured ~110
+  sequential raw reads at 0.4s with zero 429 the same day. Either those are two
+  different limiters or the older figure is wrong, and the note cannot tell them
+  apart. One API-axis figure this repo can stand behind was recorded instead: 22
+  sequential `/api/v1/` calls at 2s pacing, anonymous, zero 429.
+
 ## [0.9.0] — 2026-08-09
 
 ### Changed