## Why
File blob uploads previously failed immediately on HTTP 502 and 504 responses, even though these transient gateway errors can recover on retry.
## What changed
Treat HTTP 502 and 504 as retryable alongside 503, using the existing attempt limit, upload deadline, and server-provided retry delays.
## Testing
Expand upload retry tests to cover recovery from 502 and 504, mixed transient responses, exhausted attempts, and retry delays exceeding the remaining budget. Verify that 403, 409, and 500 responses are not retried, including responses without an Azure error code.
GitOrigin-RevId: a8e2f6bcf69338fb6d24f4c2d1ee333fb77bdbc0
## Why
A single blob upload failure previously aborted the file upload, even for a temporary `503` response or an interrupted stream.
## What changed
- Retry `503` responses and timeout, connection, body, or request errors, with at most five attempts within a shared five-minute deadline.
- Honor `x-ms-retry-after-ms` and `Retry-After`, falling back to backoff when no valid server delay is available.
- Reopen the contents for each retry while reusing the same file record and upload URL. Preserve the initial read permission check and reopen MCP file streams under the same sandbox policy.
- Record retry, recovery, and terminal failure events with a fresh client request ID for each attempt.
## Testing
Add coverage for recovery after `503` responses and interrupted streams, attempt and deadline limits, non-retryable responses, retry delay parsing, and unique request IDs. Extend the restricted-read MCP upload test to verify that both attempts send the complete file contents.
GitOrigin-RevId: 78089ecfd5076313f5784cbbc864df12d082e3b1
mtsui-oai