cloud: stop following HTTP redirects on the storage client; reject 3xx responses to mutations

[smiggleworth]

Gap cloud-29 · behavior-difference · confidence: verified · tracked in #242
Baseline: Midge 7d39f86 (0.1.1) vs Pants 2507c66. Midge paths are relative to the midge repo, Pants paths to this repo. Midge behavior is used as the proxy for the not-yet-extracted lsm-spec behavioral contract.

Prior: #62/#64/#68/#71 (related, closed: SharedHttpClient hardening did not address redirects)

Midge: the storage client is built with redirect(Policy::none()) (executor.rs:189-191). Tests:
should_stop_at_redirect_when_cloud_request_is_mutating (:1009), plus should_reject_redirect_status_when_putting_s3_object
(s3.rs:1781) and the same test for Azure and GCS (azure/gcs should_reject_redirect_status_when_putting_*).

Pants: Providers/CloudObjectStoreFactory.cs:24-40 builds SocketsHttpHandler without AllowAutoRedirect = false. The .NET
default follows up to 50 redirects and re-sends PUT/DELETE bodies and conditional headers for 307/308 (and 301/302 for non-POST)
to the Location host. Custom headers such as x-amz-security-token, x-ms-*, and x-goog-* are forwarded; only Authorization
is stripped. The provider code never sees the 3xx. No Pants test covers redirects (grep "redirect" finds nothing in src/ or test/ Cloud).

Why it matters: a misconfigured endpoint or a hostile middlebox can move conditional mutations to another origin. The session token
and SAS/signing headers are also forwarded there. Midge treats a 3xx as an error.

Acceptance criteria:

• The storage handler disables auto-redirect. A 3xx response to PUT or DELETE produces a typed error, and the test asserts that exactly one request was sent.
• Reads also do not follow redirects, or else follow them only same-origin, as a documented decision.
• Decide for the credential client separately. Midge's credential clients use reqwest's default policy, so disabling redirects there is optional.