Add sandbox retry logic

[mendral-app]

Summary

• Add exponential backoff retry to all sandbox HTTP operations when the API returns a retryable error (e.g. WORKLOAD_UNAVAILABLE), respecting 500ms→30s backoff and ~60s total budget
• Eliminates user-facing ResponseError during sandbox cold starts by automatically retrying instead of failing immediately

Details

The sandbox API returns { "error": { "code": "WORKLOAD_UNAVAILABLE", "retryable": true } } when a sandbox is scaling from zero. Previously, all sandbox operations raised ResponseError immediately on any non-2xx response without checking the retryable field.

This PR adds a _request_with_retry method to both SandboxAction (async) and SyncSandboxAction (sync) that:

1. Makes the HTTP request
2. Checks if the error response body contains retryable: true
3. If retryable, logs an info message and sleeps with exponential backoff
4. Retries until success or the 60s budget is exhausted

All sandbox data-plane operations (process, filesystem, multipart uploads) now use this method.

Resolves: https://app.mendral.com/insights/01KXVWJ0B6X2PV2MJZSNSFDVTY

---

Note

Created by Mendral. Tag @mendral-app with feedback or questions.

• View implementation session
• Addresses this insight

[SystemSculpt]

This is relevant to the dominant SDK-PYTHON-C8 Codspeed WORKLOAD_UNAVAILABLE cluster, but it does not address the Mailai missing-path 404s. Holding merge: the PR changes retry behavior across async/sync filesystem and process mutations (including POST/PUT/DELETE) with no unit tests, and Core CI is red. Please add deterministic async/sync tests for retryable vs non-retryable bodies, budget exhaustion, cancellation, response closing, and mutating-operation replay safety; align/reuse the bounded retry policy in #172 where semantics match. Tracked in ENG-4037.