API changelog maintained

Without an API-specific changelog, consumers upgrading between versions have no way to know which endpoints changed, which fields were added, or which response shapes shifted. A general project changelog that says "various API improvements" is not a substitute. iso-25010:2011 maintainability.modifiability is directly impacted: the cost of each API change is borne by consumers who must diff the implementation themselves rather than reading a curated list of what changed and what they need to update.

Start an API changelog focused exclusively on changes to the API contract. Keep it in API_CHANGELOG.md or a /changelog endpoint, separate from the general project changelog:

# API Changelog

## v1.2.0 - 2026-03-15
### Added
- GET /api/v1/users/:id/preferences
- `timezone` field on User response

### Changed
- GET /api/v1/orders now returns `items` array (was `orderItems`)

### Deprecated
- POST /api/v1/users/search -- use GET /api/v1/users?q= instead

Every entry should include the endpoint affected, what changed, and any migration action required. Date and version-tag every release.