Preserve original response bytes when Content-Type specifies a non-UTF-8 charset

Both native clients currently decode Content-Type charset and omit bodyBytes whenever decoding succeeds. JavaScript arrayBuffer()/bytes() then reconstruct UTF-8 bytes from bodyString. For example a one-byte ISO-8859-1 e9 payload becomes c3 a9, corrupting the original body. The same issue affects the duplicated iOS prefetch path.\n\nProposed correction: use lossless strict UTF-8 only for the text bridge optimization and otherwise bridge original bytes; Fetch text()/json() use UTF-8 irrespective of Content-Type charset. This also removes repeated Android charset regex/decoder allocation and the iOS charset parser. I will document the observable correction for applications relying on legacy charset decoding and verify byte-for-byte behavior for UTF-8, invalid UTF-8, Latin-1 and UTF-16 payloads.

Trace the response bridges in both native clients and the duplicated iOS prefetch path, starting with how Content-Type charset decoding determines whether bodyBytes is exposed. Compare the text bridge optimization with the original-byte path, then verify byte-for-byte behavior for UTF-8, invalid UTF-8, Latin-1, and UTF-16 payloads while confirming Fetch text() and json() use UTF-8.