Breaking change policy documented

Without a documented breaking change policy, consumers have no way to know which parts of the API are stable and which might change without notice. This matters most at integration time: a consumer building a production integration on an undocumented API is making a bet that the author's implicit stability expectations match their own. When they don't, the consumer's code breaks silently on the next deploy. iso-25010:2011 compatibility.interoperability requires that the API's stability guarantees be explicitly stated — not assumed from silence.

Add an API stability section to your README or API documentation that explicitly defines what is and is not a breaking change:

## API Stability

This API follows semantic versioning. Within a major version:
- Existing fields will not be removed or renamed
- Existing endpoint paths will not change
- Response types will not change
- New optional fields may be added to responses
- New optional parameters may be added to requests

Breaking changes (field removal, type changes, endpoint removal)
will only occur in major version bumps with a minimum 90-day
deprecation notice.

The policy must cover at least: field removal, type changes, endpoint removal, required field additions, and status code changes.