📜 Description

For gzip-compressed responses, OkHttp strips the Content-Length header during transparent decompression, so response.body.contentLength() returns -1. This caused NetworkRequestData.responseBodySize to always be unknown for replay network details on such responses.

This PR adds originalByteCount to NetworkBody, populated from the actual byte array length in NetworkBodyParser.fromBytes. NetworkDetailCaptureUtils.createRequestOrResponseInternal now uses this as a fallback when the passed bodySize is null or -1.

The fix piggybacks on the existing peekBody call — no additional network I/O. For responses larger than the peek limit (MAX_NETWORK_BODY_SIZE), the capped byte count is reported (lower bound) instead of unknown.

Example replay: https://sentry-sdks.sentry.io/explore/replays/95bf32448ef94fafb41b5164ccde5d19

💡 Motivation and Context

Session replay network details show response body size. For gzip-compressed HTTP responses (common for JSON APIs), OkHttp's transparent decompression strips Content-Length, making the size always unknown (-1). The Sentry UI shows "It is possible the network transfer size is smaller due to compression", so reporting the decompressed size is the correct behavior.

Fixes SDK-1006

💚 How did you test it?

• Added unit tests for NetworkBodyParser covering originalByteCount for both truncated and non-truncated bodies
• Added unit tests for NetworkDetailCaptureUtils covering the bodySize fallback logic (unknown → uses byte count, explicit → preserved, body capture off → unchanged)
• Verified existing tests pass

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps