Parse Retry-After safely

[terjekv]

Why

RateLimitError.retry_after currently calls float() on the header. That accepts values the HTTP grammar rejects (negative, fractional, NaN, and infinity) and ignores the standard HTTP-date alternative. Callers can therefore receive unsafe or missing retry scheduling information.

RFC 9110 section 10.2.3 defines Retry-After as either a non-negative decimal integer or an HTTP date:
https://www.rfc-editor.org/rfc/rfc9110.html#section-10.2.3

What changed

• parse non-negative ASCII decimal delay-seconds
• parse HTTP-date values into seconds relative to response receipt
• clamp past HTTP dates to zero
• return None for negative, fractional, non-finite, malformed, or unrepresentably large values
• keep the parser in shared transport code for sync/async parity
• document the public retry_after behavior and update the unreleased changelog

Verification

• uv sync --extra dev
• uv run ruff format --check .
• uv run ruff check . (including active PLR0913)
• uv run mypy
• uv run bandit -q -r src scripts
• uv run zizmor .
• uv run pytest --cov — 75 passed, 95.37% coverage
• uv run mkdocs build --strict
• uv build

The local Docker daemon remains unresponsive even to docker ps; CI provides the pinned Hubuum v0.0.3 e2e evidence.