feat: revamp retry classification and switch to @mondaydotcomorg/api …

[josephsamonday]

Summary

• Replaced monday-sdk-js with ApiClient from @mondaydotcomorg/api
  in MondayClientCallMondayApiTask. ClientError is normalized into
  the existing MondayError shape so downstream retry logic is unchanged.
• Flipped retry classification from an allow-list to a deny-list. We now
  retry by default and only treat errors as terminal when they match
  TERMINAL_MONDAY_ERROR_CODES (e.g. Unauthorized,
  ResourceNotFoundException, InvalidArgumentException, …) or a
  non-retryable 4xx. 429 and 423 remain retryable; 5xx stays retryable.
• Extracted classification into isRetryableMondayError and
  getRetryAfterSeconds in retry-utils, and moved constants into
  src/constants/monday-error-codes.ts.
• Loosened MondayApiError / MondayErrorExtensions types so we
  tolerate error_code vs code and missing status_code from the
  API's varied error shapes.
• Added unit tests for retry-utils, sqs-producer, the API task, and the
  queue processor's retry decisions.

Motivation

The previous allow-list (only 429 / MAX_CONCURRENCY_EXCEEDED /
COMPLEXITY_BUDGET_EXHAUSTED) silently dropped transient failures that
didn't match those exact signals. Inverting to a deny-list of known
terminal errors lets us retry unknown/transient failures by default
while still failing fast on genuinely non-retryable cases.

Test plan

• npm test passes (new suites for retry-utils, sqs-producer,
  api task, queue processor)
• Verify against a real Monday API token that a successful query
  returns data through the new ApiClient path
• Verify a 429 / retry_in_seconds response is honored end-to-end
  via the SQS retry path
• Verify a terminal error (e.g. Unauthorized) does NOT retry