fix: use Monday's retry_in_seconds directly without adding backoff

[josephsamonday]

Summary

• ApiRequestQueueProcessor.getRetryAfterValue was adding calculateBackoffDelay(attempts) on top of Monday's retry_in_seconds, causing the retry delay to grow exponentially with attempts. On attempt 9 with retry_in_seconds=37 this produced ~910s, which then exceeded SQS's 900s DelaySeconds limit and caused the requeue itself to fail (Value 910 for parameter DelaySeconds is invalid).
• When Monday provides retry_in_seconds, that value is now used verbatim. Exponential backoff is reserved for the fallback case (no retry_in_seconds in the error).
• SqsProducer now clamps DelaySeconds to [0, 900] via a small clampDelaySeconds helper as defense-in-depth, so any future caller producing an out-of-range delay can't blow up SendMessage.
• Test retry delay calculation updated to assert the delay is exactly Monday's retry_in_seconds (60) instead of retry_in_seconds + backoff.

Test plan

• yarn typecheck passes
• yarn test — all 107 tests pass
• Verify in staging: a 429 with retry_in_seconds: N produces a requeue with DelaySeconds = N (not N + backoff)
• Verify in staging: high-attempt retries no longer fail with DelaySeconds must be >= 0 and <= 900

🤖 Generated with Claude Code