Rate limits and quotas are documented

An API that returns 429 without documenting its limits forces consumers to discover the ceiling experimentally — in production, under real traffic, during a critical path. Rate limit headers (X-RateLimit-Remaining, Retry-After) are useless if consumers don't know to read them. Undocumented quotas also block capacity planning: a company considering integration cannot evaluate whether a free tier meets their use case without knowing the specific numbers. iso-25010:2011 analysability requires that all operational constraints on a system be documented, not discovered.

Add a Rate Limits section that specifies exact numbers, the window, and the response headers:

## Rate Limits

| Plan | Requests | Window |
|------|----------|--------|
| Free | 100 | per minute |
| Pro | 1,000 | per minute |

Every response includes rate limit headers:
- `X-RateLimit-Limit`: Maximum requests in the current window
- `X-RateLimit-Remaining`: Requests left before you are throttled
- `Retry-After`: Seconds to wait on a 429 response

Do not write 'rate limits apply' without the actual numbers. Vague rate limit documentation is treated the same as missing documentation.