docs(changelog): per-version keep-a-changelog entries (RAN-61)

[aksOps]

Summary

Replaces the meta-pointer CHANGELOG.md with keep-a-changelog 1.1.0 format plus per-version sections for v0.0.1, v0.0.2, and v0.0.3.

The bestpractices.dev autofill scans for per-version headers and skips meta files, so the previous file kept release_notes_status stuck at Unmet — No release notes file found and held project 12628 at 42/43 MUST. With per-version headers in place, a board-side re-trigger of the autofill should flip the criterion to Met (target: 43/43 MUST).

What changed

• Rewrote CHANGELOG.md with keep-a-changelog headers (## [0.0.3] — 2026-04-23, etc.).
• Each version section uses keep-a-changelog category headings (### Added, ### Changed, ### Fixed, ### Security, ### Upgrade impact, ### Known limitations) sourced from the existing GitHub Release bodies.
• Top-of-file documents the format, SemVer adherence, and the existing release.yml workflow so future releases keep entries in sync.
• Cross-links each version to its tag and PRs.

Out of scope (per RAN-61 description)

• Back-filling gh release notes — release.yml is workflow_dispatch-only with notes as a required input; rewriting historic releases is a separate ask.
• Auto-writing CHANGELOG entries from release.yml on release — track separately if desired.

Test plan

• File lints as valid markdown (rendered locally).
• After merge, board re-triggers autofill at https://www.bestpractices.dev/en/projects/12628?as=edit and confirms release_notes_status flips to Met (43/43 MUST).

Closes RAN-61.

🤖 Generated with Claude Code