Fix CHANGELOG.md: restore CRLF after an accidental LF renormalize (#2694 fallout)

[erikdarlingdata]

What

My own merge-conflict resolution while landing #2694 (merging origin/dev's #2693 into my branch) committed the resolved CHANGELOG.md without the .git/info/attributes CHANGELOG.md -text override in place — the standard trap this repo's CHANGELOG workflow requires guarding against. Git silently renormalized the entire file to LF on staging, and that landed on dev via #2694's merge commit.

Fix

Rebuilt the file with CRLF on every line. Verified via a CR-stripped diff against the current dev content that this is byte-identical modulo line endings — no textual content changed, only the line-ending restoration.

No build/test impact (a .md file, not compiled).

🤖 Generated with Claude Code

[claude]

Reviewed. This is a doc-only, single-file change (CHANGELOG.md), so the T-SQL style rules, Lite/Darling parity, and security/performance concerns don't apply here — but I verified the core claim in the PR description rather than taking it on faith:

• Extracted the pre-image (3057 removed lines) and post-image (3057 added lines) from the diff, stripped the diff marker and any \r, and hashed both sequences independently → identical MD5 (54fb9759c936570a86cd7ba90780672b). Confirms this is byte-identical modulo line endings, positionally, for every line — not just "looks the same."
• Confirmed the direction: the removed lines have bare \n, the added lines have \r\n (verified with cat -A). So this restores CRLF, matching the stated intent, not the reverse.
• .gitattributes already sets * text=auto eol=crlf. The PR description says the actual guard that failed was an unversioned .git/info/attributes entry (CHANGELOG.md -text) — i.e., the safeguard against this recurring lives only in the maintainer's local git config, not in the repository.

Given that, one process suggestion (non-blocking, since this PR itself is a correct, minimal fix):

Nothing in-repo currently prevents this from happening again — no CI check verifies CHANGELOG.md's line endings, and the local-only .git/info/attributes override that's supposed to prevent it isn't documented anywhere in CONTRIBUTING.md or committed as repo config. Since the PR body calls this "the standard trap this repo's CHANGELOG workflow requires guarding against," it might be worth either (a) adding a cheap CI grep/lint step that fails if CHANGELOG.md contains a bare \n not preceded by \r, or (b) documenting the local .git/info/attributes requirement in CONTRIBUTING.md so it isn't tribal knowledge. Otherwise this exact fallout is likely to recur on the next merge-conflict resolution.

No functional/security/performance issues found.