Preserve Uint8Array types in Fetch, Blob, and SafeFetch byte APIs #388

Part of #382 — v1.0.0 alpha readiness.

Problem

Native byte readers and byte-stream chunks are Uint8Array, not ordinary JavaScript/ReScript arrays:

• src/fetch/Request.res:33-L37
• src/fetch/Response.res:81-L85
• src/file/Blob.res:23-L45
• src/fetch/FetchTypes.res:152 and src/fetch/FetchTypes.res:197
• src/safe-fetch/SafeFetch.resi:97-L102

A packed-consumer reproduction compiled bytes->Array.map(byte => Int.toString(byte)) as an ordinary-array operation, but returned Uint8Array [65, 66, 67] containing numbers instead of an array of strings. Array-specific methods can also be absent. The existing SafeFetch bytes test only checks Result.isOk.

Acceptance criteria

• Use the native Uint8Array.t representation consistently in Request, Response, Blob/File byte readers and native byte-stream chunk types.
• Update SafeFetch's implementation/interface/documentation and downstream type fixtures consistently.
• Assert byte contents and the runtime representation, not only success.
• Cover native Request/Response/Blob readers and a stream chunk.
• Add a negative compile regression preventing these results from being used as ordinary arrays.
• Preserve SafeFetch response identity and error-as-value behavior.

Performance constraint

Do not hide the mismatch with an implicit O(n) Array.from conversion. Any convenience conversion should be explicit and separate from the raw native contract.

Coordination

Use the regression infrastructure in #383. Source fixes can be developed in parallel, but this issue should close with executed regression coverage, not only a successful compile.