Surface rate-limit headers (x-ratelimit-remaining / x-ratelimit-reset)

[martinkersner]

Split off from #116 (now closed) — the only unaddressed item; the rest of #116's polish list shipped in #125/#126/#128.

Problem

The client parses Retry-After on 429 (map_error_status in src/api.rs, Error::RateLimited { endpoint, retry_after }) but ignores any x-ratelimit-remaining / x-ratelimit-reset-style headers. Callers have no way to pace themselves proactively — they only learn they're throttled once they've already been 429'd.

Step 1 — confirm what the API actually returns (blocking)

Before designing any surface, capture real response headers from a live DataMaxi endpoint and record which rate-limit headers (if any) are present and their exact names/format (remaining count? reset epoch vs delta-seconds? limit?). If the API sends none, this issue closes as wontfix with that finding documented.

Step 2 — surface them (only if they exist)

Options to weigh once header shape is known:

• Attach to a successful response (e.g. a RateLimit struct available alongside the decoded body / on the Client), so callers can pace before hitting 429.
• Also enrich Error::RateLimited with the parsed values.

Done when

• Documented finding of which rate-limit headers the live API returns.
• If present: callers can read remaining/reset without triggering a 429; covered by a unit test parsing the header form.
• If absent: issue closed with the finding recorded.

Context: src/api.rs map_error_status, parse_retry_after, Error::RateLimited.