Spot the bug in this LangChain reliability wrapper that combines `with_retry` and `with_fallbacks` the wrong way

The bug is the order of the two wrappers. Composition reads inside-out: the wrapper applied first is the innermost, and the wrapper applied last is the outermost. Exceptions bubble from inner to outer, so the inner wrapper sees them first. As written, `primary.with_fallbacks([backup])` runs first, so the fallback is the inner wrapper. When OpenAI raises a transient error (429, timeout, server error), the fallback wrapper catches it immediately and switches to Anthropic. Anthropic responds successfully. The outer `.with_retry(stop_after_attempt=3)` never has a chance to retry the primary because the fallback already converted the failure into a success via the backup. This defeats the intent. The author wanted to retry transient OpenAI failures up to three times before giving up and switching providers. What actually happens is a single OpenAI failure causes an immediate switch to Anthropic, and the retry only protects the composite. Which barely ever fails. The fix is to swap the order. `primary.with_retry(stop_after_attempt=3)` first wraps the primary with retry. Now transient OpenAI errors get retried. Only after the retry budget is exhausted does the exception escape. The outer `.with_fallbacks([backup])` then catches it and switches to Anthropic. The rule to remember: the wrapper you want to fire first goes innermost, which means it must be the first one applied.

The bug is wrapper-order reversal. LangChain composes Runnable wrappers inside-out. The first wrapper applied is the innermost; the last wrapper applied is the outermost. When the inner Runnable raises an exception, the innermost wrapper sees it first. Only if that wrapper re-raises does the next wrapper out get a chance. The written order is `primary.with_fallbacks([backup]).with_retry(stop_after_attempt=3)`. Reading inside-out: primary is innermost, then fallback, then retry on the outside. When OpenAI raises a transient 429, the fallback (inner wrapper) catches it instantly and routes to Anthropic. Anthropic returns a response. The retry (outer wrapper) sees a successful call. There is nothing to retry. The author's intent to retry the primary three times before failing over never executes. The corrected order is `primary.with_retry(stop_after_attempt=3).with_fallbacks([backup])`. Reading inside-out: primary innermost, retry wraps primary, fallback wraps the retry. On the same 429, the retry catches it and retries the primary up to three times. If all three retries fail, the exception escapes the retry boundary. The outer fallback catches it and switches to Anthropic. The heuristic that prevents this mistake: write the wrappers in the order they should fire on a failure, where the first to fire is applied first. Or equivalently: the wrapper closest to the underlying call goes first; the wrapper that runs as the last line of defense goes last. The same pattern matters for any composed Runnable wrappers. `with_listeners`, `with_config`, custom wrappers. Composition order is execution order in reverse.