changelog-releaselisted

# Changelog & Release — Communicate What Changed Users read release notes to answer one question: "does this affect me, and must I act?" Write for them, not for the commit log. ## Workflow 1. **Collect the delta** since last tag: `git log <last>..HEAD --oneline`, plus merged PRs (`gh pr list --state merged`). Read the diffs of anything user-visible — commit messages undersell. 2. **Decide the version by contract math**: - MAJOR: anything a consumer could break on (removed/renamed API, changed defaults, dropped support for Node/X/Python version, stricter validation) - MINOR: additive (new endpoint/flag/option, new capability) - PATCH: fixes with identical external behavior - Pre-1.0: minor = breaking is acceptable IF (and only if) the README/docs say so — otherwise treat as 1.0 rules. - Ambiguous? Ask: "if someone's automation depends on yesterday's behavior, does it break?" Yes → MAJOR. 3. **Write notes in Keep-a-Changelog shape, impact-ordered**: ```markdown ## [2.4.0] — 2026-08-31 ### ⚠️ Breaking - `parseConfig()` throws on unknown keys (was: silent ignore). Pass `{ strict: false }` for old behavior. ### Added - Retry policy on `fetchOrders` — configure via `retry: { times, backoff }` ### Fixed - Session cookie refreshed before expiry check — long-lived tabs no longer log out (#482) ### Internal - CI matrix adds Node 24 ``` 4. Rules for each line: verb-first, link the PR/issue, name the config/flag users must know, quan