Expose body-free HTTP status and Retry-After metadata #1356

Problem

The reqwest Streamable HTTP client preserves structured details for selected
authentication failures, but callers cannot reliably distinguish a 429 or
5xx response or inspect Retry-After. Falling through to response parsing can
also turn the failure into a body-related error that no longer exposes the HTTP
status.

Proposed direction

Return a typed, body-free error for 429 and 5xx responses immediately after
the GET or POST completes:

pub struct HttpStatusError {
    pub status: u16,
    pub retry_after: Option<String>,
}

Only a valid UTF-8 Retry-After value of at most 128 bytes would be retained.
The response body, request authentication, and other headers would not be
stored in the error.

This is intentionally narrower than #388, which discusses broader rate-limit
behavior. It is also separate from #1246: this proposal does not add response
size configuration, buffered-body limits, trait changes, or body-reading code.
For 429 and 5xx, it returns before reading a body at all.

Planned validation

Loopback reqwest tests would exercise POST 429 and GET 503 responses with
Retry-After, private bodies, and private request state, then verify that the
typed error retains only the intended metadata. A helper test would cover a
valid retry value, invalid UTF-8, and a 129-byte value. Both GET and POST call
sites would use the same classification helper.

Would this error shape and narrow status set fit the transport API?