Crystal HTTP::Client and OAuth2 middleware integration for automatic 401 WWW-Authenticate handling

When a Crystal HTTP::Client receives a 401 Unauthorized response that includes a WWW‑Authenticate header after a successful TLS handshake, the standard library does not automatically retry the request with refreshed credentials. Developers must decide whether to propagate the error, invoke custom middleware, or implement a retry loop that extracts the challenge and obtains a new token from a vault or secret store.

The goal is to define a clear, least‑privilege‑aware integration point between HTTP::Client and credential‑refresh mechanisms that works across fiber‑shared clients without leaking headers or requiring per‑fiber client duplication. Constraints include the absence of built‑in token‑lifecycle callbacks, the need to keep TLS verification settings intact, and the requirement that any retry logic does not inadvertently resend BasicAuth in cleartext over non‑TLS connections.

What should be the default behavior of HTTP::Client when a 401 with WWW‑Authenticate is observed? Should the library provide an optional on_auth_challenge callback, or is it preferable to leave error handling entirely to application‑level middleware? How can least‑privilege credential scopes be enforced when retrying requests across fibers that share a single client instance?