perf!: serialize requests once in batchAddRequests

[vdusek]

Description

• Mirroring fix: Make batch_add_requests split batches by serialized payload size apify-client-python#953.
• batchAddRequests stringified every request twice: once in sliceArrayByByteLength to measure the batch, and again in the serializeRequest interceptor when sending. Axios then ran its default transformRequest on top, because transformRequest: undefined in the instance config falls back to the defaults, and that default validates a JSON string body by parsing it in full. Each batch body was stringified twice and parsed once more.
• Each request is now serialized once up front. The byte lengths decide the batch boundaries (commas and brackets counted, which the old measurement skipped) and the same strings are joined into the batch body, sent with an explicit content-type: application/json. The interceptor passes a string body with an explicit content type through untouched, and the axios instance sets transformRequest and transformResponse to []. That also removes the validation re-parse for every JSON body the client sends.

Issue

• Closes Avoid double JSON serialization in batchAddRequests #972

Breaking changes

• A string body declared as JSON but not valid JSON (for example setRecord with contentType: 'application/json' and a non-JSON string) is sent as it is. Axios used to double-encode it into a JSON string literal.
• A request too large for the payload limit is rejected before any batch is sent. It used to be detected only when its batch came up, with earlier batches already in flight.
• The protected _batchAddRequests and _batchAddRequestsWithRetries take the serialized entries, and _batchAddRequests no longer re-validates a batch the public method already validated. The API report is updated.

✍️ Drafted by Claude Code

[github-actions]

⚠️ There are broken links in the documentation.

See more at https://github.com/apify/apify-client-js/actions/runs/34862046980#summary-104036487629

[barjin]

Just some nits / thinking out loud, otherwise lgtm.

Thanks @vdusek !

[barjin]

which getRecord() can't parse back

This is kinda annoying, but understandable.

I'm not sure whether we should automatically parse the KVS contents based on the content-type in the client, but that ship has sailed, I suppose.

[vdusek]

Yeah, I'm merging this. However, feel free to start a follow-up Slack discussion about it. I'd probably lean toward dropping this automatic parsing of KVS records based on their content type, but I think it deserves a bit more investigation and discussion first with a broader audience (also #product-dev-tools channel). I opened a follow-up issue for it: #1067, and we should discuss it before the v3 release.