fix(crawl): retry a stop on 429, 502 and 504

[StefanoGuerrini]

Stacked on #36. Merge that first; this PR's base is its branch.

What changed

ZenRowsCrawlClient.stop() now retries a stop answered 429, 502, 503 (any problem code, crawl_busy included) or 504. It uses the same retry count as before (retries) and the same wait: the server's Retry-After, capped at 30 s, or 1 s when the header is missing or unusable. After the last retry it raises the last CrawlAPIError.

Other statuses (for example 500 or 4xx) are still raised at once. Network errors on stop are not retried, as before. The shared transport's rule for POST is unchanged; the retry stays inside stop().

The stop and constructor docstrings now describe this.

Why

Stopping a crawl is safe to repeat: stopping a crawl that already ended answers 200 with its status. But stop is a POST without an Idempotency-Key, so the shared transport never retries it, and stop() itself retried only a 503 crawl_busy. A 429, 502 or 504 went straight to the caller, who had to write their own retry loop for a call the SDK already knows is safe to repeat.

Tests

• A stop answered 429, 502, 503 (non-crawl_busy) or 504 once, then 200, succeeds after one wait of the Retry-After value.
• A stop answered 502 four times with retries=3 raises the 502 after three 1 s waits.
• A stop answered 500 is not retried.
• The Retry-After cap test now covers 429 as well as 503 crawl_busy: 3600 waits 30 s, -1 and nan wait 1 s, 2 waits 2 s.
• The existing crawl_busy retry tests pass unchanged.

uv sync --all-extras && uv run pytest -q && uv run ty check src && uv run ruff check && uv run ruff format --check src tests

Result on Python 3.12: 229 passed, 1 deselected; ty, ruff check and ruff format all pass.

---

Generated by Claude Code

[StefanoGuerrini]

Folded into #31, which now carries this change, so the Crawl client ships as one pull request.

---

Generated by Claude Code