CHANGELOG with entries per version

Consumers upgrading from v1.x to v2.x need to know what broke and what migrated. Without a CHANGELOG.md, they must diff the entire package history, read all commit messages, or trial-upgrade hoping nothing explodes. ISO 25010 modifiability requires that the system's evolution be trackable. A changelog is also a trust signal: maintained packages have changelogs; abandoned packages don't. For packages consumed in regulated or enterprise environments, documented version history is often a procurement requirement.

Create CHANGELOG.md in the project root following the Keep a Changelog format, with one entry per released version.

# Changelog

## [2.3.1] - 2026-03-15

### Fixed
- Fixed retry logic that caused duplicate requests on timeout

## [2.3.0] - 2026-03-01

### Added
- New `retryConfig` option for customizing retry behavior

### Changed
- Default timeout increased from 5s to 10s

The most recent entry must match the current version in package.json. For teams using conventional commits, conventional-changelog or release-it can generate this automatically on each release. Keep a changelog even if you use GitHub Releases — not all consumers browse GitHub.