Recover transient reads and honor Retry-After in both SDKs

[MagMueller]

Both SDKs abandon completion polling after one transient 503 and ignore the API's numeric Retry-After on 429 responses.
Retry GET 502/503/504 within the existing retry count, honor integer-second Retry-After within the existing ten-second wait cap, and add up to 250ms jitter.
Larger numeric waits return the original error; date-form headers retain the published SDK's normal backoff, and POST 5xx or transport failures are still not replayed.
Persistent GET failures can make four attempts instead of one and retry waits add to elapsed time; timeouts remain per attempt.
The five-file diff changes two HTTP clients, two test files and the shared policy note; 324 offline tests, both type checks and package builds, and public completion/browser-creation replays passed.

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

2 issues found across 7 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="browser-use-node/README.md">

<violation number="1">
P3: This PR changes Retry-After handling (honoring integer-second values within the 10s cap), but instead of updating the README Retries section it deletes it entirely. The removed text's remaining claims are still accurate in the new implementation — up to three retries (`maxRetries` default 3), 429 for all methods plus GET 502/503/504, exponential backoff starting at 1s capped at 10s, 250ms jitter, and per-attempt timeout — so this drops still-valid user-facing documentation rather than correcting the single outdated sentence (Retry-After extending waits to 60s). Update the section to describe the new integer-second cap instead of removing all retry documentation.</violation>
</file>

<file name="browser-use-python/README.md">

<violation number="1">
P3: Removing the whole retry paragraph drops SDK error-handling documentation that is still accurate. Only one detail changed: the code now honors integer-second Retry-After up to _MAX_RETRY_DELAY = 10.0 seconds (browser-use-python/src/browser_use_sdk/_core/http.py), not 60. The rest is unchanged — GET 502/503/504 and 429 are retried up to three times with exponential backoff and jitter, POST 5xx and transport errors are not replayed, and the timeout applies per attempt. Update the paragraph's Retry-After cap to 10 seconds instead of deleting it, so the published README still documents this behavior.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Fix all with cubic | Re-trigger cubic</sub>