batch_add_requests() doesn't retry unprocessed requests #1134

When the API rate-limits a batch insert, it answers 200 and lists the requests it skipped in unprocessedRequests. RequestQueueClient.batch_add_requests() appends those to the result and moves on (request_queue.py#L412-L491, async #L941-L1075). Under load, a caller that adds 1,000 requests can get back a few hundred unprocessed ones and has to write its own retry loop. The HTTP client's retries don't help here, since the response is a success.

The JS client retries the unprocessed requests up to maxUnprocessedRequestsRetries times (default 3) with exponential backoff starting at minDelayBetweenUnprocessedRequestsRetriesMillis (default 500 ms). It drops already processed requests by uniqueKey before each retry and records each round with unprocessed requests as a rate-limit error in the client statistics (request_queue.ts#L408-L479, defaults at #L43-L44).

Expected behavior

batch_add_requests() (sync and async) retries unprocessed requests with backoff, with the retry count and minimum delay configurable, and records the rate-limited rounds via Statistics.add_rate_limit_error(). Only the requests still unprocessed after the last attempt end up in unprocessed_requests.

✍️ Drafted by Claude Code