mach upload reports success without validating the HTTP response

(the description was AI generated based on the conversation I had with it)

## Problem

`mach upload` can print throughput metrics and exit successfully even when the server rejects or redirects the request. For example, an unauthenticated upload to an Access-protected endpoint receives HTTP 302, but the command still reports a successful-looking upload. The same behavior can hide responses such as 413 or 500.

`CountingBody::Finished` only means Hyper consumed the generated request body. It does not mean the server accepted it. `ThroughputClient` publishes `InflightBody` before awaiting the response, and the eventual response status is logged but never validated.

## Expected behavior

The standalone upload command should only succeed when both conditions are true:

- The request body completed.
- The server returned a successful 2xx response.

Redirects for streaming POST requests should not be followed automatically. Non-2xx responses should produce a non-zero exit and include the HTTP status in the error.

## Suggested approach

Preserve the early `InflightBody` needed for progress tracking, but expose a separate asynchronous response result containing the status, headers, or transport error. Initially consume it in `mach upload`; RPM and saturation can define their own failure policies separately.

## Acceptance criteria

- 2xx upload responses succeed.
- 3xx, 4xx, and 5xx responses fail with the status shown.
- Request-body completion is not treated as HTTP success.
- HTTP/1 and HTTP/2 behavior is covered.
- Existing streaming/no-`Content-Length` behavior is preserved.

## Priority / workaround

Low priority for the current investigation. Tests can use the regular public speed-test endpoint (`https://h3.speed.cloudflare.com/__up`) instead of the Access-protected staging environment.

Start at the standalone mach upload command and trace how ThroughputClient publishes InflightBody and how CountingBody::Finished is consumed. Separate the asynchronous HTTP response result from request-body completion, then run or add coverage for HTTP/1 and HTTP/2 responses. Done means 2xx responses succeed, non-2xx responses fail with their status, and streaming without Content-Length remains intact.

Written by the indexing model from the issue text.