Bump reqwest to 0.13

[jasonhernandez]

One of several sequenced PRs in the crypto migration toward rustls + aws-lc-rs for everything.
Specifically:

• This PR — mechanical bump from reqwest 0.12 → 0.13. Keeps the existing native-tls backend for now to scope the change to just the version bump. Does not flip the TLS backend.
• Next in the reqwest chain — the HTTP-clients-to-rustls PR (crypto: switch HTTP clients from native-tls to rustls #35947 in the plan) swaps native-tls for rustls with aws-lc-rs across all reqwest consumers. That's where the real TLS backend change happens.
• In parallel — the Azure SDK migration (persist: migrate to the GA Azure SDK crates #36216, stacked on this) adopts the new azure_core 0.35 series, which defaults to reqwest_rustls + aws-lc-rs on its own; that's a concrete step forward on the Azure path even before the workspace-wide flip.

Summary

• Bump reqwest 0.12.28 → 0.13.2, reqwest-middleware 0.4.2 → 0.5.1, reqwest-retry 0.8.0 → 0.9.1.
• default-features = false on reqwest so the 0.13 default changes (now default-tls = rustls, new system-proxy feature) don't ambush us mid-bump.
• Explicitly list the feature set we had in 0.12 (including native-tls / native-tls-vendored for now) plus the two newly-opt-in features we need: query (used by cloud-api and frontegg-client) and system-proxy (was implicit in 0.12).

The native-tls pin here is a temporary consequence of keeping this PR scoped to the bump — the crypto migration's HTTP-clients PR is where the switch to rustls actually lands.

Known workarounds for incompatible call sites

Two places still need reqwest 0.12 because their trait ecosystem is pinned there. Both are narrow and clearly labeled; both go away as the related migrations land.

1. src/persist/src/azure.rs — Azurite test path only. The old code plumbed a custom reqwest::Client through TransportOptions inside the if account == EMULATOR_ACCOUNT branch to apply short BlobKnobs per-attempt / read / connect timeouts (5s–10s) to the Azurite test client. azure_core 0.21 pins reqwest 0.12 internally, so our 0.13 Client no longer implements its HttpClient trait.
   • Production impact: zero. The else branch (real Azure Blob Storage) never set a custom transport — it uses BlobServiceClient::new(...) which gets the SDK's default reqwest client. That behavior is unchanged.
   • Test impact: minimal. Azurite runs on localhost, so falling back to the SDK's default timeouts has no observable effect on test reliability.
   • The outer knobs.operation_timeout() is preserved via the retry policy's max_total_elapsed in both branches.
   • The Azure SDK 0.35 migration (persist: migrate to the GA Azure SDK crates #36216, stacked) restores the emulator-path timeout plumbing against the new SDK.
2. src/storage-types/src/connections.rs — AwsCredentialLoad impl. The reqsign::AwsCredentialLoad trait (re-exported from iceberg) is defined against reqwest 0.12. Added a versioned reqwest_0_12 alias dep in [workspace.dependencies] and use it only for the single trait-impl parameter. Removable once iceberg upstream bumps to a reqsign that supports reqwest 0.13 — tracked as a multi-hop ecosystem blocker (reqsign 0.17 was a breaking API rewrite; neither iceberg nor opendal have migrated).

Cargo.lock

~27 new packages (quinn for HTTP/3, rustls-platform-verifier, wasm-streams, newer windows-sys). Both reqwest 0.12 and 0.13 coexist in the tree — the 0.12 copy comes in via azure_core 0.21 and reqsign 0.16 and is needed only for the two workarounds above. Exempted in deny.toml's skip list.

Test plan

• cargo check --workspace --all-targets — clean
• cargo --locked deny check bans sources — bans ok
• bin/lint-cargo — exit 0
• Full cargo test run / CI green
• Smoke-test at least one TLS client path (ccsr, frontegg-client, or similar) against a real endpoint to confirm native-tls still works at 0.13 before the crypto migration's rustls switch lands

🤖 Generated with Claude Code