Apply DoorDash's documented retry-backoff strategy and idempotency key to Drive API calls

Steps

1. Classify error responses per DoorDash's documented guidance: 4xx = do not retry (fix the request), 429 = retry after at least 1 second and avoid bursts, 5xx = retry with exponential backoff and jitter
2. Implement retries with DoorDash's recommended parameters (up to 3 attempts, backoff factor ~2, delay between 1s and 5s, randomized jitter)
3. Pass a stable external_delivery_id on delivery-creation calls so a retried create-delivery request is treated as idempotent rather than creating a duplicate delivery
4. Use an existing resilience library (e.g. Polly, Resilience4j, or a retry npm/pip package) instead of hand-rolling backoff logic
5. Log retry attempts, elapsed time, and error responses, and escalate to DoorDash support if retries are consistently required