fix: retry complete pinned binary downloads

[art049]

Retry pinned binary downloads after transient request, HTTP, and response-body failures.

The runner could fail after all benchmarks completed when a GitHub release asset request was interrupted. Retrying only the request phase did not cover transfers interrupted after response headers arrived.

Apply one exponential-backoff policy around the complete download attempt. Request errors, body-read failures, 5xx, 408, and 429 responses are retried up to five times. Permanent client errors, local filesystem failures, and SHA-256 mismatches remain fatal.

This addresses the intermittent ruff CI failure.

[greptile-apps]

Greptile Summary

This PR moves pinned-binary retry handling around the complete download attempt so request, HTTP-status, and response-body failures share one exponential-backoff policy.

• Adds retry classification and complete-attempt retry handling for pinned downloads.
• Uses a plain download client to avoid nested middleware retries.
• Adds coverage for aborted connections, truncated bodies, retry exhaustion, retryable server errors, permanent client errors, and checksum mismatches.

Confidence Score: 5/5

The PR appears safe to merge, with complete-attempt retries preserving fatal handling for permanent HTTP, filesystem, and checksum failures.

The download path now retries request and response-body interruptions through one bounded policy, avoids nested client retries, and retains destination integrity checks without an identified blocking or non-blocking defect.

Important Files Changed

Filename	Overview
src/cli/run/helpers/download_file.rs	Introduces complete-download retry handling and comprehensive focused tests without an identified correctness regression.
src/request_client.rs	Adds a plain reqwest client for downloads so the new outer retry loop remains the sole retry layer.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Start pinned binary download] --> B[Send request]
    B -->|Request error| R[Transient failure]
    B -->|HTTP 408, 429, or 5xx| R
    B -->|Permanent HTTP error| F[Fatal error]
    B -->|Success| C[Read complete response body]
    C -->|Body-read error| R
    C -->|Success| D[Create and write destination]
    D -->|Filesystem error| F
    D -->|Success| E[Verify SHA-256]
    E -->|Mismatch| G[Delete file and fail]
    E -->|Match| S[Success]
    R --> H{Retries remaining?}
    H -->|Yes| I[Exponential backoff]
    I --> B
    H -->|No| F

Loading

_{Reviews (1): Last reviewed commit: "fix: retry complete pinned binary downlo..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 17 untouched benchmarks

---

_{Comparing claude/codspeed-memtrack-download-error-slr131 (4d21603) with main (6eac757)}