fix(sdk): add max retry limit to rate-limited API calls

[zhoufengen]

Summary

The ensure_rest_api_call_respecting_rate_limit function in the Python SDK retries indefinitely on persistent HTTP 429 responses, which can cause callers to hang forever when account quota is exhausted or rate limits are misconfigured.

Changes

• Replace while True loop with a bounded for loop capped at MAX_RATE_LIMIT_RETRIES = 10 attempts
• Re-raise the ApiError after exhausting all retries
• Add attempt count to log messages for better observability

Testing

• The change is backward-compatible: normal rate-limited calls that succeed within 10 retries behave identically
• The retry decorator (retry_decorator.py) already caps at 3 attempts for other errors; this brings rate limit handling in line with that pattern
• Edge case: after 10 consecutive 429 responses, the original ApiError is raised to the caller

Related Issues

None (discovered during code review)

---

This PR was authored with AI assistance. All changes have been reviewed for correctness.

[baz-reviewer]

When the 10th 429 retry is exhausted, this raise rethrows the original ApiError instead of converting it to opik.exceptions.OpikCloudRequestsRateLimited with headers/retry_after—should we wrap the last 429 here?

_{Finding type: AI Coding Guidelines | Severity: 🟠 Medium}

---

Want Baz to fix this for you? Activate Fixer

Other fix methods

Prompt for AI Agents:

Before applying, verify this suggestion against the current code. In
sdks/python/src/opik/api_objects/rest_helpers.py around lines 40-45 inside
`ensure_rest_api_call_respecting_rate_limit`, the code currently re-raises the original
`ApiError` when the final 429 retry is exhausted (`attempt >= MAX_RATE_LIMIT_RETRIES -
1`). Refactor this branch to convert that last rate-limit failure into the standardized
`opik.exceptions.OpikCloudRequestsRateLimited`, populating it with the response
`headers` and the computed `retry_after` (use
`rate_limit.parse_rate_limit(exception.headers).retry_after()` when possible, otherwise
fall back to 1). Ensure the raised exception type matches what callers in `dataset.py`
and `annotation_queue.py` (and their existing retry guidance in
`online_message_processor.py` / `queue_consumer.py`) expect.