Nothing tells a user what changed between releases

The repository has no `CHANGELOG.md`. What a release publishes instead is GitHub's auto-generated "What's Changed" list — the merged PR titles, in merge order. For `v0.1.1` that list is hundreds of lines, and the great majority of them read `Bump from x.y.z to x.y.z by @dependabot`. Someone deciding whether to upgrade has to read all of it to find the few entries that concern them, and those entries are phrased as PR titles rather than as changes to the program they run.

`docs/MIGRATION_GUIDE.md` covers the configuration changes a user has to make, which is a different question from what changed. Nothing answers the second one.

## Why after 0.2.0, not before

Writing this retroactively would mean reconstructing the whole `0.1.1` → `0.2.0` span from the commit log, which is most of the work and the least valuable part of it — nobody upgrading to `0.2.0` needs a 0.1.x history. Starting the file at `0.2.0` makes the first entry one written while the release is fresh, and keeps the `0.2.0` release itself unblocked.

## Acceptance

- `CHANGELOG.md` exists at the repository root, with `0.2.0` as its earliest entry and an `Unreleased` section above it. [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) is the format unless something else fits better.
- Entries say what changed for someone using nostui, in the same voice as a commit summary here: the claim, not the file. A dependency bump appears only where it changed what the program does.
- `CONTRIBUTING.md` says when the file is updated — per pull request, or as a release step — so the next release does not have to decide it again.
- `0.1.0` and `0.1.1` stay out of the file; the GitHub release pages remain their record.

Whether entries are hand-written or generated from the Conventional Commits history (`git-cliff` and the like) is open. Generation is cheap to try and easy to abandon, but it inherits the dependabot noise unless the commit types are filtered, so it is worth a look rather than an assumption.