Raise RateLimitError w/ retry_after on HTTP 429

[kylekeesling]

Why

PASS Tools' daily inventory email run bursts ~340 jobs at 9:00 UTC and trips MyTankInfo's rate limit (Sentry PASS-TOOLS-BQ). handle_response mapped 429 to the generic MyTankInfo::Error — the same class as 400 — so callers couldn't distinguish rate limiting from malformed requests, couldn't retry_on it in ActiveJob, and the Credential auth fallback misread a 429 during token refresh as a rejected refresh token and fired a second auth call.

What

• New MyTankInfo::RateLimitError < Error raised on HTTP 429. Same message format as before, and it subclasses Error, so existing rescues are unaffected.
• error.retry_after exposes the response's Retry-After header normalized to seconds (handles both delay-seconds and HTTP-date forms); nil when the header is absent.
• JwtClient#authenticate!/refresh! propagate it (they go through post_request → handle_response); tests verify a 429 on refresh raises RateLimitError and does not trigger the full re-auth fallback.
• Version bump to 1.3.0 + CHANGELOG entry.

Downstream (planned in pass-tools, not part of this PR)

• EmailDeliveryJob: retry_on MyTankInfo::RateLimitError
• Credential#fresh_my_tank_info_access_token!: re-raise RateLimitError instead of falling back to full auth

Testing

rake test: 97 runs, 265 assertions, 0 failures.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}