Write a retry-with-backoff decorator that preserves the wrapped function correctly

Write a retry-with-backoff decorator for the function(s) described below. This needs to be a decorator other functions can reuse, not a one-off retry loop copy-pasted into a single call site.

FUNCTION(S) TO WRAP
fetch_exchange_rate(currency: str) -> float, which calls an external HTTP API.

RETRYABLE VERSUS FATAL
Retry on httpx.TimeoutException and httpx.ConnectError; never retry on a 4xx client error (httpx.HTTPStatusError with status < 500).

BACKOFF REQUIREMENTS
Exponential backoff starting at 0.5s, doubling each attempt, max 5 attempts, capped total wait of 30s.

SYNC OR ASYNC
Async only — the wrapped function is always a coroutine function.

REQUIREMENTS
1. Use functools.wraps on the inner wrapper function, so the decorated function keeps its original __name__, __doc__, and signature — a decorator that doesn't do this breaks introspection, breaks Sphinx-generated docs, and makes stack traces confusing about which function actually failed.
2. Only retry the exceptions named in Retry on httpx.TimeoutException and httpx.ConnectError; never retry on a 4xx client error (httpx.HTTPStatusError with status < 500).; anything else propagates immediately on the first attempt. Naming an exception "fatal" and then silently retrying it anyway is worse than not having retry logic at all, because it delays a failure that should have surfaced immediately.
3. Implement exponential backoff with jitter (not fixed-interval retries) matching Exponential backoff starting at 0.5s, doubling each attempt, max 5 attempts, capped total wait of 30s., and enforce a hard cap on either the number of attempts or the total elapsed wait time — an unbounded retry loop against a dependency that's actually down just multiplies load on a struggling system instead of giving up cleanly.
4. Log each retry attempt at a level that won't spam production logs on transient blips but will surface a pattern of repeated failures — include the attempt number, the exception, and the wait time before the next attempt.
5. If Async only — the wrapped function is always a coroutine function. calls for both, write two decorators (or one that detects and dispatches correctly) — do not write a sync decorator and just slap async def on the inner call, since that produces a coroutine that's never awaited and silently does nothing.
6. On final failure after exhausting retries, raise the original exception (or wrap it in a custom RetriesExhausted exception that keeps the original as __cause__) — never swallow the failure and return None, which hides the failure from the caller entirely.
7. Make the decorator's parameters (max attempts, base delay, retryable exceptions) real arguments to the decorator factory, not constants baked into the wrapper's body — a decorator that can only be configured by editing its own source isn't actually reusable across the different call sites that will each have different tolerances for how long a retry sequence should run.
8. If the wrapped function accepts arguments that could be exhausted or invalidated by a retry (a request body that's actually a generator, consumed on the first attempt and empty on the second), name that risk explicitly rather than assuming every argument is safe to reuse across attempts.

OUTPUT FORMAT
1. The decorator, fully typed with functools.wraps applied, with its tunable parameters as factory arguments.
2. One example of it applied to a real function from fetch_exchange_rate(currency: str) -> float, which calls an external HTTP API..
3. A short note on what happens on the exception it should NOT retry, showing it propagates immediately.
4. Confirmation that every argument passed to the wrapped function is safe to reuse unchanged across every retry attempt, or a named exception to that.