Retry Logic for Rate-Limited Warehouse Alert API Calls

A rate limit error (HTTP 429) in a warehouse alert pipeline should be treated first as a control-flow issue, with the worker pausing its sends rather than continuing to fire requests. The recommended approach is to respect the server's Retry-After header when present, otherwise apply exponential backoff with jitter, always capped by a maximum retry count. Each attempt should be logged with a stable shipment identifier, attempt number, status code, and delay so incidents can be reconstructed later. Logs serve as evidence only and do not themselves trigger notifications, so operators need a separate polling or health-check system for alerting. Retry limits and elapsed-time budgets should be configurable and tested against the business alert deadline, since per-request retry budgets can still cause stale messages.