ci: evaluate git-cliff release automation (cd.yaml)

Nobody has claimed this yet.

## Context

PR #16 adds a `cd.yaml` (Continuous Deployment) that, on a `v*.*.*` tag push, generates a changelog with [git-cliff](https://git-cliff.org/) (`orhun/git-cliff-action`) and drives a GitHub release.

> **Design/decision issue** — this changes the release flow and needs new config, so let's agree the shape before implementing.

## Open questions

- **Relationship with existing workflows.** `publish.yaml` (PyPI) and `docs.yaml` both trigger on `release: published`. Does `cd.yaml` (tag-triggered) *create* the release that then triggers those, or do we consolidate? Need one coherent release story.
- **git-cliff config.** Requires a `[tool.git-cliff]` section in `pyproject.toml` (commit parsing, changelog template). None exists yet.
- **Changelog destination.** Source writes `docs/CHANGELOG.rst` — do we want a committed changelog file, release-notes-only, or both?
- **Trigger model.** Tag-push vs. the current release-published flow (#16's `CONTRIBUTING` also referenced a `prepare_release.py` script we did not adopt).

## Proposed tasks

- [ ] Decide the release flow (tag → cd → release → publish/docs)
- [ ] Add `[tool.git-cliff]` config
- [ ] Add `.github/workflows/cd.yaml` (SHA-pinned — note #16 uses `orhun/git-cliff-action@main`, a moving ref we must pin; least-privilege `contents: write` for release creation)
- [ ] Reconcile with `publish.yaml` / `docs.yaml`

Read PR #16, then compare the existing .github/workflows/publish.yaml and docs.yaml with the proposed cd.yaml flow. Review pyproject.toml, CONTRIBUTING, and the referenced prepare_release.py script before deciding the trigger and changelog destination. Done means the release path is agreed, configuration and workflow changes are defined, and the existing workflows are reconciled.

Written by the indexing model from the issue text.