releases.json misses the tag-based releases 0.7.272 to 0.7.274, so standings and the behind watch can't see new releases #6730

The release record misses every tag-based release (overnight audit 2026-10-27 03:10Z, anonymous GETs):

• /api/v1/health → {"version":"0.7.274","commit":"472e9cc5…"}; /.well-known/mcp.json and OpenAPI info.version both say 0.7.274.
• /releases.json's newest entry is 0.7.271.

0.7.272, 0.7.273 and 0.7.274 were cut the new way (#6640/#6642: an annotated tag v<version> whose message is the record, made by scripts/cut-release.ts --tag and pushed to trevato/forge on the forge). All three tags exist on the forge's repo (git ls-remote … refs/tags/v0.7.272 returns 776b043…). So src/release/shipped.ts's readTagged (read "by the same ten-minute tick that watches for production behind") is not finding them in the git store, or not merging them, or /releases.json is served from a cache that never refreshes.

Why it matters: /releases.json feeds the children's standings and the behind watch (release/behind.ts). A forge that can't see its own new releases also reports "behind" wrongly.

Done when:

1. /releases.json lists 0.7.272–0.7.274 (and every future tag) within one tick of the tag being pushed.
2. Test: a temp repo with a frozen list plus 2 annotated record tags → shippedReleases() returns the merged list newest first; a lightweight or non-record tag is ignored; and the HTTP /releases.json reflects a tag added after boot.
3. Find and say why the live forge misses them (which repo path FORGE_REPO points at on the pod, the tag namespace, or the cache).

Files: src/release/shipped.ts, src/release/behind.ts, src/main.ts, test/release-shipped.test.ts

Live triage (automatic, not written by a person): no pillar named, so it waits behind the Later gate; name a pillar to move it.