Return HTTP 503 for failed external API requests caused by 503s and other retryable errors

Here are two known types of retryable external API failures (there may be more to the list):

1. Database lock contention (TransactionRetry errors, e.g. oxidecomputer/omicron#3304)
2. Database connection exhaustion (All claims are used errors, e.g. https://github.com/oxidecomputer/customer-support/issues/443#issuecomment-2946710294)

The errors are usually encountered in a saga (returned as HTTP 500 or 503 by the underlying components) and are in turned surfaced as 500 errors. As they are known failure modes under high concurrency or request load, they can probably be HTTP 429 errors to provide the right signal back to the clients (i.e., please retry).

The issue does not identify files, tests, or entry points. Start by tracing how saga failures from external API requests become HTTP 500 or 503 responses, then determine which retryable errors should produce 503 or 429 and add coverage for the listed lock-contention and connection-exhaustion cases.