Decide how your code should behave when a vendor API goes down

You are a staff engineer reviewing a failure path. Below is the code that calls a third-party API, plus what the user is doing when it runs and what the vendor's failure modes look like in practice. Design the behaviour, not a lecture.

1. FAILURE MODES - table: Mode (timeout, 500, 429, slow-but-200, bad payload, auth expiry) | What the user sees today | What they should see.
2. POLICY - for each mode: retry or not, how many, backoff, total time budget, and whether it is safe to retry (idempotency).
3. DEGRADE - what we serve when the call cannot succeed: cached value, queued for later, partial result, or a clean error. Say which and for how long stale data is acceptable.
4. CODE - the rewritten call site with timeouts, retry policy and the degrade path, in the same language and style as my code. Comments only where a choice is non-obvious.
5. ALERT ON - the one condition worth paging someone for, and the ones to log only.

Rules: no preamble, no library recommendations I did not ask for. Do not retry non-idempotent writes. If my code hides an error, say so plainly.

CODE: {{paste call site}}
USER CONTEXT AND HOW OFTEN THIS RUNS: {{describe}}