Http.Error.BadStatus loses response body on non-success HTTP statuses

Goal

Retrieve the server‑sent response body when an Elm http request results in a non‑2xx status, so that error messages returned as JSON can be decoded and displayed.

Constraints and uncertainty

• The Http.Error.BadStatus constructor carries only the integer status code; the response body, headers, and raw payload are not attached.
• Standard decoders such as expectJson and expectString are invoked only for successful responses, leaving server error bodies inaccessible through the normal Http path.
• It is unclear whether the elm/http library can be configured to expose the body alongside BadStatus without abandoning the built‑in success/failure routing, or if users must always drop to lower‑level APIs like expectStringResponse.

Open questions

• Can elm/http be extended or configured to attach the raw response body (or a decoded JSON payload) to BadStatus values?
• What are the practical trade‑offs of switching from the standard expectJson/expectString flow to expectStringResponse for handling non‑2xx responses?
• Does the library provide a helper or pattern that allows decoding JSON bodies from error statuses while preserving the existing Http.Error union type?