docs: curated human-readable CHANGELOG (satisfies BestPractices release_notes)

[aksOps]

Why

OpenSSF BestPractices `release_notes` explicitly says:

The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes).

Our v0.0.1 and v0.0.2 GitHub release bodies were just the auto-generated PR list (`--generate-notes` output) — disqualified. The prior `CHANGELOG.md` was a stub pointing at those same auto-generated bodies.

Changes

CHANGELOG.md — rewritten as a curated human-readable log:

• v0.0.1 — described as the "first stable release", covers product scope: GraphRAG pipeline, loaders, LLM abstraction, query engine, surfaces (CLI / REST / MCP / SPA), SQLite storage, signed releases, and explicit known limitations (darwin-arm64 only, pre-1.0 API).
• v0.0.2 — targeted single-change note: Scorecard workflow cadence, with explicit "upgrade impact: drop-in replacement, no API/CLI/schema changes".
• Unreleased — tracks governance files, release-pipeline rewrite, CI simplifications.

GitHub release bodies — already updated via `gh release edit` for v0.0.1 and v0.0.2 with the same curated content. Takes effect immediately; CHANGELOG.md is the in-repo permanent form.

What this unlocks

• `release_notes` criterion flips from `Unmet` → `Met` on the next BestPractices scan.
• Future releases keep the `--generate-notes` auto-population as a starting point, and the release workflow's notes-file step can be enhanced to require a curated summary for significant releases.

Test plan

• CI passes
• CHANGELOG.md renders on GitHub repo root
• `gh release view v0.0.1` and `gh release view v0.0.2` show curated notes (already applied)
• Next BestPractices scan flips `release_notes` to Met

🤖 Generated with Claude Code