docs: make the release cadence explicit

Brian described the practice: Unreleased is the staging area for what is going
into the next release, and the version bump happens when enough has
accumulated to be worth shipping — not per commit, not per merge. The
convention already implied it ("never touch the changelog at a merge
boundary") but never said it outright.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Qcu9ByJfuKBQxmrWb8rSrN

CLAUDE.md

@@ -63,6 +63,10 @@ at a merge boundary.**
     polling cadence, or the monitor fan-out.  The meter has a **single TCP
     slot**, so a change that bounces the connection is an operational event,
     not just a code change.
+- **Releases are cut on judgement, not on a schedule or a merge.**  `Unreleased`
+  is the staging area for whatever is going into the next release; when enough
+  has accumulated to be worth shipping, it gets a number and a date.  Nothing
+  about a merge to `dev` triggers a release.
 - **Cutting a release** is its own `chore(release): vX.Y.Z` commit on `dev`,
   renaming `## [Unreleased]` → `## [X.Y.Z] - YYYY-MM-DD` and bumping the
   version in `app/main.py` (the FastAPI `version=` argument).