Remove three duplicate CHANGELOG issue link-reference definitions

[erikdarlingdata]

What

Removes the three duplicate issue link-reference definitions in CHANGELOG.md, leaving one definition per issue.

PR #2889 defined the 37 issue link references the CHANGELOG used but never declared. It did not check the other direction — three issues were each defined twice:

Issue	Copy kept	Copy removed
#2860	in the [1.0.0] block	second copy, same block, 10 lines later
#828	in the [2.7.0] block	copy in the newer [2.11.0] block
#887	in the [2.9.0] block	copy in the newer [2.11.0] block

All three duplicates pointed at identical URLs, so rendered Markdown never changed. This is cosmetic — worth finishing while #2889 has the area fresh.

Which copy was kept, and why

Note the layout differs from a plain "all three sit in the bottom block": only #2860 was duplicated within one block. #828 and #887 were each defined in two different release sections' blocks, because both sections reference those issues in prose.

That raised a fair question — is the per-section block meant to be self-contained, making these deliberate? The file answers it. Of the 77 issue refs used in prose across more than one release section, 75 are defined exactly once, and in 74 of those 75 the single definition sits in the block of the oldest section referencing it, with newer sections reusing it. Link reference definitions are document-scoped in Markdown, so that works fine.

So single global definition is the established convention, and #828/#887 were the two outliers — not intentional design. The kept copy follows the 74/75 pattern (bottom-most) rather than a literal "delete the second one." For #2860, where both copies shared a block, the first was kept.

Verification

Run in both directions, so an empty result isn't a broken grep. A planted duplicate is still caught by the identical command form:

$ # positive control: post-change file + one planted duplicate
$ grep -oE '^\[#[0-9]+\]:' <copy-with-planted-dupe> | sort | uniq -d
[#777777]:                # <- detected, command form is live

$ grep -oE '^\[#[0-9]+\]:' CHANGELOG.md | sort | uniq -d
                          # <- empty, no duplicates remain

• 1102 definition lines / 1102 unique definitions — exact match
• zero bracketed [#NNNN] refs used-but-undefined; zero defined more than once
• diff is exactly 3 deletions, 0 insertions

Line endings (bug #2858 guard) — staged with a plain git add, no hash-object --no-filters:

working tree: 3283 CRLF, 0 bare LF     (all-CRLF, per `* text=auto eol=crlf`)
committed blob: 0 CRLF, 3283 bare LF   (all-LF)

Also checked: still-undefined refs

Asked to confirm whether #2889's "37" was exhaustive. It was — there are now zero refs used in bracketed [#NNNN] form but left undefined.

The four flagged as possibly-still-undefined (#2806, #2472, #2893, #2906) do not appear in CHANGELOG.md at all — not bracketed, not even as bare text. Nothing to add, per "only add definitions for refs actually used in bracketed form."

One unrelated observation, not changed here: [#85] and [#86] are defined but never referenced — orphan definitions rather than duplicates. Happy to prune separately if wanted.

Based on dev.

🤖 Generated with Claude Code

[claude]

Reviewed. This is a documentation-only change (CHANGELOG.md), no code/SQL/Lite-Darling parity surface touched. Verified independently:

• All three removed lines (#828, #887, #2860) still have exactly one surviving link-reference definition each, with usage/definition counts matching the PR description.
• grep -oE '^\[#[0-9]+\]:' CHANGELOG.md | sort | uniq -d returns empty — no duplicate definitions remain anywhere in the file.
• Diff is exactly the 3 deletions described, nothing else touched.

No issues found. LGTM.