Add a CHANGELOG.md to track releases

## Summary

There is no `CHANGELOG.md` in the repository. Release notes exist only as GitHub's auto-generated commit lists on the [Releases page](../releases) (`generate_release_notes: true` in [.github/workflows/release.yml](../blob/main/.github/workflows/release.yml)).

## Current state

- `.github/workflows/release.yml` creates a GitHub Release with `generate_release_notes: true`, which produces a flat list of merged PR titles. This is useful as raw input, but it isn't curated: it doesn't distinguish breaking changes from additive ones, doesn't group by category (features/fixes/docs), and isn't available as a versioned file inside the repo for offline/vendored consumers.
- No `CHANGELOG.md`, `HISTORY.md`, or equivalent exists at the repo root or in `docs/`.

## Why this matters

Before upgrading a dependency, teams typically want a quick, curated summary of what changed and — critically — what might break, without having to read through every merged PR title. This is especially relevant here since there's currently no documented versioning policy either (see the related versioning issue): a curated changelog is one of the most direct ways to communicate upgrade risk in the absence of strict semver guarantees.

## Suggested resolution

- Add a `CHANGELOG.md` following a standard format (e.g. [Keep a Changelog](https://keepachangelog.com/)).
- Populate it going forward as part of the release process, ideally categorized (Added/Changed/Fixed/Removed, with breaking changes called out explicitly).
- Optionally backfill entries for past releases (`v0.1.0-beta` through `v1.1.1`) using the existing auto-generated release notes as source material.

## Acceptance criteria

- [ ] `CHANGELOG.md` exists at the repo root, following a consistent format.
- [ ] The release workflow/process is updated to require a changelog entry per release.

Look at the existing release notes on the GitHub Releases page to understand past changes. Review the .github/workflows/release.yml file to see the current automation. Create a CHANGELOG.md file at the repository root following the Keep a Changelog format, categorizing changes from recent releases. Ensure the file is added and the release process documentation is considered for future updates.

Written by the indexing model from the issue text.