chore(release): 0.1.23, and retain 0.1.22 as failed-preflight evidence

[rldyourmnd]

What happened

0.1.22 was cut minutes ago with its CHANGELOG heading dated 2026-09-21, taken from a +05 local clock. Its target commit eeb9953e is dated 2026-09-20 in UTC. check_release_ledger compares the heading date against the UTC author date of the tag's target commit, so release run 35540240146 rejected it in preflight:

[FAIL] release-ledger-tags
    - 0.1.22 is dated 2026-09-21 in CHANGELOG.md but its tag is 2026-09-20

Every other one of the ~40 preflight validators passed, and the signed promotion envelope on the tag is GitHub-verified (verified: true, reason: valid). Only the date was wrong.

The tag points at a tree that carries the wrong date, so no follow-up commit can make 0.1.22 pass. It is unrecoverable.

What this does

• 0.1.23 carries the identical payload under a UTC-correct date: the vendored tool-cache composite action and the retired GARM label vocabulary.
• 0.1.22 is retained in KNOWN_UNRELEASED_TAGS as failure evidence rather than deleted, which is how this repository already handles 0.1.4, 0.1.5 and 0.1.7. 0.1.7 failed for this same timezone reason — the exception table calls it "timezone-dependent ledger date" — so this is the fourth instance of one recurring trap.

Verification

• check_release_ledger.check (core tier) — no findings
• check_release_ledger.check_tags — reports only the expected pre-tag state for 0.1.23; the tag 0.1.22 exists but CHANGELOG.md has no heading for it problem is resolved by the exception
• Input contracts were diffed across all 14 reusables the estate calls for the whole 0.1.16..0.1.22 range: no input removed, none newly required

🤖 Generated with Claude Code