CHANGELOG.md has a second, empty [Unreleased] heading buried in the release history

[macanderson]

Problem

CHANGELOG.md contains two ## [Unreleased] headings. The second one is
empty and sits in the middle of the released history, between the [0.1.2] and
[1.0.0] sections:

## [Unreleased]        <- line 20, the real one, has content
...
## [0.1.2] — 2026-08-01 (crate release)
...
## [Unreleased]        <- empty, and out of chronological order
## [1.0.0] — 2026-08-11 (stable protocol and crate release)

Two things are wrong with it:

• It is empty, so it renders as a heading with nothing under it.
• It is in the wrong place. Unreleased means "not yet shipped"; this one is
  pinned between two shipped versions, below a release that came after it.

The likely cause is a release cut that added the new version heading without
removing the [Unreleased] placeholder above it, but that is a guess from the
shape — I did not confirm it against the commit that introduced it.

Why it is worth fixing rather than ignoring

.github/workflows/changelog.yml drafts missing entries into [Unreleased]
when a merge forgets them. Any tool — that workflow, a release script, or a
person — that searches for the [Unreleased] heading and takes the first or
last match now has two answers to choose between, and only one is right.
Nothing has picked the wrong one yet as far as I can tell, which makes this
cheap to fix now and awkward to debug later.

Worth checking as part of the fix: does changelog-ai.sh (or whatever the
workflow calls) anchor on this heading, and if so, which match does it take?

What done looks like

• The stray empty ## [Unreleased] between [0.1.2] and [1.0.0] is deleted.
• Exactly one ## [Unreleased] remains, at the top.
• If any script anchors on that heading, it is confirmed to still work — and
  ideally asserts there is exactly one, so this cannot silently return.

Verify

rg -c '^## \[Unreleased\]' CHANGELOG.md    # expect 1

Files

• CHANGELOG.md
• .github/workflows/changelog.yml and .github/scripts/changelog-ai.sh — check
  whether either anchors on the heading.

Context

Noticed in PR #109 while checking that CHANGELOG.md had auto-merged sensibly
after a rebase. It is pre-existing on main — git show origin/main:CHANGELOG.md
has both headings, at lines 20 and 178 — and was left alone there to keep that
PR about schema identity.

[macanderson]

Related to #149 — and the order these are fixed in matters

#149 reports the other half of this. .github/workflows/changelog.yml inserts drafted entries with perl -pi -e matching /^## \[Unreleased\]$/, and perl -p runs the body on every matching line. With two ## [Unreleased] headings in the file, the bot writes each entry twice — once under the real heading and once under the stray one documented here.

So:

• This issue is the trigger — the duplicate heading.
• The changelog bot writes its entries twice, and the check that would notice always says OK #149 is the mechanism — a substitution that fires on every match rather than the first, plus a guard that exit 0s on the exact breakage it exists to catch.

The hazard for whoever picks this up: deleting the stray heading makes #149's symptom vanish while leaving both of its defects in place. The bot would still double-write the moment a second ## [Unreleased] ever reappears — which it will, since release tooling adds and moves those headings — and the guard would still never fail. Closing #149 on the evidence that "the changelog no longer duplicates" would therefore be wrong.

Fix both, and fix #149 on its own terms: anchor the insertion to the first match only, and give the guard a test that fails on a two-heading changelog.