feat: API timeout config, Retry-After support, and configurable retry

[TheArchitectit]

Summary

• Add TimeoutConfig to HTTP client builder with connect_timeout (30s default) and request_timeout (5min default)
• Configurable via CLAW_API_CONNECT_TIMEOUT and CLAW_API_REQUEST_TIMEOUT env vars
• Add with_timeout() builder to both AnthropicClient and OpenAiCompatClient
• Parse Retry-After header on 429 responses and respect it over exponential backoff
• Add apiTimeout config block to ~/.claw/settings.json with connectTimeout, requestTimeout, and maxRetries fields
• Add retry_after field to ApiError::Api for propagating rate-limit backoff hints
• Add is_retryable_400() to detect transient gateway 400 errors (not real bad requests)
• Add "no parseable body" to CONTEXT_WINDOW_ERROR_MARKERS

Problem this solves

Hung API calls

Before: a request to a slow/unresponsive API endpoint would block indefinitely. No timeout, no way to configure one.

Fix: TimeoutConfig with sensible defaults (30s connect, 5min request) and env var / settings.json overrides.

Ignored Retry-After headers

Before: on 429 (rate-limited) responses, the client always used exponential backoff, ignoring the provider's Retry-After header. This caused unnecessary delays or premature retries.

Fix: parse_retry_after() extracts the header value, and the retry loop respects it over exponential backoff when present.

Transient gateway 400 errors treated as fatal

Before: some providers (especially OpenAI-compat backends like glm-5.1-fast) return 400 with bodies like "HTTP 400 from backend (no parseable body)" or "connection reset by peer" — these are not real bad requests. They're transient gateway errors caused by the backend being overwhelmed or unable to parse an oversized payload. The client treated all 400s as fatal, immediately failing the request.

Fix: is_retryable_400() checks 400 response bodies for transient gateway error signatures and marks them as retryable, so the retry loop can attempt the request again.

Context window overflow disguised as 400

Before: when a request exceeds the model's context window, some OpenAI-compat backends can't even parse the oversized payload and return 400 "no parseable body" instead of a proper context_length_exceeded error. Without recognizing this as a context overflow, is_context_window_error() returns false and the auto-compact retry loop (#2808) never triggers — the user sees an opaque 400 with no recovery path.

Fix: Added "no parseable body" to CONTEXT_WINDOW_ERROR_MARKERS so is_context_window_error() correctly identifies these disguised context overflow errors. This enables the progressive auto-compact retry loop (PR #2808) to kick in and shrink the session until it fits.

After

• Requests timeout after 5 minutes by default (configurable)
• 429 responses with Retry-After header use the provider's suggested delay
• Transient gateway 400s are retried instead of failing immediately
• Context overflow disguised as 400 is correctly detected for auto-compact retry
• Users can configure timeouts in settings.json:

{
  "apiTimeout": {
    "connectTimeout": 30,
    "requestTimeout": 300,
    "maxRetries": 8
  }
}

Test plan

• cargo test --workspace — all tests pass (1 pre-existing env-specific failure in lsp_discovery)
• cargo build --release — clean build
• Tested end-to-end with bloated session against OpenAI-compat provider — progressive auto-compact retry triggered and completed successfully
• Verify timeout triggers on slow endpoints
• Verify Retry-After header is respected on 429
• Verify settings.json apiTimeout overrides defaults
• Verify is_retryable_400() correctly classifies transient gateway 400s

💘 Generated with Crush