fail when a released changelog section is edited

[haribo]

Why

An entry added to a released section of CHANGELOG.md is invisible to every check.

It has now happened twice, in the same place, for the same reason:

• chore(changelog): move the unless entry to the version that ships it #630 — the unless entry landed in the published [0.12.0] section. Fixed by hand, and the
  same PR found that the entry had never been word-checked either, because the rule only looks
  inside [Unreleased].
• fix(std): match a group name literally in user.group #668 — fix(std): observe the sysctl drop-in as well as the kernel #667's entry for observe the sysctl drop-in as well as the running kernel #658 landed in the published [0.14.0] section, four days later.

The mechanism is not carelessness, it is a property of the file. A release rolls
[Unreleased] into [X.Y.Z] and leaves a fresh [Unreleased] behind that carries only the
sections the next PRs add. So right after a release, "the first ### Fixed in the file"
belongs to the version just published. Anything that appends relative to a section heading —
a script, an editor macro, a person scrolling — lands in the wrong one, and the result reads
perfectly.

test/changelog-rule.sh cannot see it: it validates the entries inside [Unreleased], so
an entry that is not there is not checked, it is absent.

Build

A check that a released section has not changed. The cheapest honest form: every
## [X.Y.Z] section is immutable once its tag exists, so compare each one against the same
section at that tag and fail on a difference.

git show vX.Y.Z:CHANGELOG.md   # the section as released

That is exact rather than heuristic, needs no new file to maintain, and gives a message that
can say which version was edited and how. It needs the tags present in the checkout — CI
fetches them for the release workflow, but the depth used by the other jobs has to be checked
before relying on it.

Deliberate consequence: a correction to a published section — a typo, a broken link — then
fails the gate. That is the right default (the section is history), and the escape is to say
so in the PR and let a human override, not to weaken the check.

Validation

• Moving one word in a released section turns the check red, naming the version.
• [Unreleased] is untouched by the new check — the word-count rule already owns it.
• The check is added to the list CLAUDE.md tells a contributor to run before opening a PR, or
  it is a check nobody runs.

Out of scope

Preventing the misfile in the first place (a --unreleased insertion helper, a lint on section
order). Worth considering later; catching it is what stops it shipping.

[haribo]

Audit — and a third instance, older than both

Running the check before writing it down turned up what the issue did not know.

The defect has happened three times, not twice. The oldest has been in the file since
August and nobody saw it:

version	commit	what
[0.2.2]	2c11460 (#277, 7 Aug)	a ### Fixed entry appended to a section tagged 4 Aug
[0.12.0]	#630	the unless entry
[0.14.0]	#667, repaired in #668	#658's entry

Survey of all 18 released sections against their tags: 16 identical, 2 divergent —
[0.2.2] above, and [0.9.0].

[0.9.0] is the fact that changes this issue's design. Its divergence is deliberate:
713cd07 (#556) added a ### Migration block the day v0.9.0 shipped, because the breaking
entry named plan syntax only while the same rule governs ~{…} in a template. That was the
right call, and the check this issue proposed — published sections are immutable, differ and
fail — would have blocked it.

So the goal is not that published notes cannot be edited. It is that they cannot be edited
invisibly. Two designs were weighed; the second shipped:

• recorded digests in a committed file — a deliberate edit updates the digest, so the diff shows
  it. Rejected: a digest can be updated without anyone reading what changed, and it is one more
  file to keep in step at release time, which is when attention is lowest.
• comparison against the tag plus a named allowance, which is the shape
  test/e2e/def-coverage.sh already uses successfully for its one exemption: named, argued, and
  carrying what it costs.

[0.2.2] is named in that list too, and not as a legitimate edit — as the defect's first
instance, left in place. The reasoning is in the script: moving the entry to the version that
actually shipped it would make that section diverge from its tag, so any repair of a
historical misfile only moves the divergence. And the authoritative record is already right —
the GitHub release notes for v0.2.2 were generated from the tag and never contained it.

On the issue's remaining doubt

It needs the tags present in the checkout — CI fetches them for the release workflow, but the
depth used by the other jobs has to be checked before relying on it.

Checked: actions/checkout@v7 with no fetch-depth is a depth-1 clone with no tags, so the
check would have been a no-op in CI. The coverage job's checkout now sets fetch-depth: 0,
with the reason on the line.

[haribo]

Delivered in #670, squashed on develop.

test/changelog-frozen.sh compares each ## [X.Y.Z] section against the same section at its
tag, with the extraction release.yaml uses — so it compares what was actually published.

Design B, after running the check changed the answer. [0.9.0] diverges deliberately
(#556 completed a breaking release's migration note the day it shipped), so the immutability
this issue proposed would have blocked work that was right. The goal is that a published section
cannot be edited invisibly, not that it cannot be edited — hence comparison plus a named
allowance carrying its reason, the shape def-coverage.sh already uses. A digest file was the
alternative and was rejected: a digest can be updated without anyone reading what changed.

Three instances, not two. [0.2.2] had been wrong since August — 2c11460 (#277, 7 Aug)
appended to a section tagged 4 Aug. It is in the allowance list labelled as the defect, not as a
legitimate edit, and deliberately not repaired: moving the entry would make the section that
actually shipped it diverge from its tag, and the published v0.2.2 notes never contained it.

Confirmed in CI rather than assumed, which is what this issue asked for. actions/checkout@v7
with no fetch-depth is depth-1 with no tags, so the check would have failed outright — it now
sets fetch-depth: 0, and the run log shows the comparison happening:

coverage  Run bash test/changelog-frozen.sh  OK — 16 released changelog section(s) match their tag

Mutation-tested: an entry inserted into [0.13.0] turns it red, printing the diff and naming the
version. Added to the pre-PR list in CLAUDE.md.