fix(api-client): bound HTTP timeouts and stop retry log spam

[RapidPoseidon]

Why

Recurring reports of "connection errors" during benchmark participant uploads, most recently adding Grok Image Imagine 2.0 (Thinking) to bmk_1Pet6iHzbf6RQu — on a healthy connection.

The server was not at fault. During that upload window Rapidata.Asset.API logged zero errors and every POST /participant/{id}/sample that arrived returned 200. All the failures were client-side transport errors (ReadError [WinError 10053], ConnectTimeout [WinError 10060]), and two REST-client defects turned a brief local hiccup into a stalled run buried in warnings.

What was wrong

1. Timeouts were never applied. _build_timeout returned None when no _request_timeout was passed — the default for every generated call — and httpx treats an explicit None as no timeout, not use the client default. Only omitting the argument inherits the default:

omit timeout kwarg       -> raised ReadTimeout after 2.0s
explicit timeout=None    -> still hanging when killed at 20s

Effect in traces: single upload requests hanging 87s, 290s and 314s, each pinning one of the 25 upload worker threads.

2. ReadError was never retried. _is_retryable_error covered ConnectError, RemoteProtocolError, ConnectTimeout and ReadTimeout. But ReadError/WriteError are the NetworkError siblings of ConnectError — a local firewall or TLS-inspecting proxy aborting a live request surfaces as one of those, not as a timeout. ReadError was 98 of ~100 failures on one run and skipped the transport retry entirely.

3. Retry logging was per-attempt at WARNING. The default log level is WARNING, so every retried attempt printed a line — across thousands of concurrent requests, the failures that never recovered were buried under the ones that did.

What changed

	Before	After
Unset request timeout	None → wait forever	USE_CLIENT_DEFAULT → connect=15s read=120s write=120s pool=60s
ReadError / WriteError / PoolTimeout	not retried	retried
Per-attempt retry log	one WARNING each	DEBUG + one throttled WARNING per 30s with a per-reason breakdown
Per-sample upload failure	ERROR (even when the sweep recovered it)	INFO — the post-sweep summary stays authoritative
Batch failure report	one error block per failed sample	first 5 + ... and N more

Retrying ReadError/WriteError means the server may already have received the request — the same caveat ReadTimeout retries already accept, so this widens no risk class. The sample endpoint is idempotent in effect (the backend rejects a duplicate with 409, which the SDK treats as success).

rest.py is generated, so openapi/templates/rest.mustache carries the identical change (verified in sync).

Verification

• 16 new tests in tests/api_client/test_rest_retry.py — timeout resolution, the retryable-error matrix, and the throttle's suppression behaviour.
• End-to-end against a socket that accepts and never replies: the real _get_session_defaults() + _build_timeout(None) composition now raises ReadTimeout and classifies it retryable, where it previously hung indefinitely.
• pyright src/rapidata/rapidata_client → 0 errors. black applied.
• Full suite: 102 passed. The 4 failures in tests/rapidata_client/audience/ pre-exist on the base branch (verified by stashing) and are untouched by this change.

Follow-up, not in this PR

upload.maxWorkers defaults to 25, which is what makes a filtering middlebox abort connections in the first place. Lowering the default is a behaviour change for every user, so it is worth deciding separately.

---

🔗 Session: session-5ba57819