fix: recover when TextDecoder rejects Uint8Array views

[jeanpierrecarvalho]

Fixes #883

Summary

This hardens the SDK stream decoding path for environments where TextDecoder.decode() rejects Uint8Array views or subarrays and only accepts a plain ArrayBuffer.

The runtime change keeps the normal path the same, but retries with bytes.slice().buffer when decodeUTF8() hits that TypeError.

Why

On AWS Lambda nodejs22.x, users reported stream decoding failures with:

Failed to execute 'decode' on 'TextDecoder': parameter 1 is not of type 'ArrayBuffer'

I reproduced the SDK-level failure mode around the public streaming helper path and verified that the fallback recovers cleanly.

What changed

• keep the TextDecoder instance instead of caching a bound decode function
• try decoder.decode(bytes) first
• on TypeError, retry with decoder.decode(bytes.slice().buffer)
• add a focused regression test for decodeUTF8()
• add a higher-level regression test for messages.stream() under stricter TextDecoder behavior

Validation

• ./node_modules/.bin/jest tests/internal/utils/bytes.test.ts tests/api-resources/MessageStream.test.ts --runInBand
• real AWS Lambda nodejs22.x repro using the public messages.stream() path
  • before fix: probe failed with the ArrayBuffer error
  • after fix: same probe completed and returned the final streamed message

Notes

I could not make a minimal direct TextDecoder.decode(Uint8Array view) probe fail natively on the exact Lambda runtime I tested in isolation, so I don't want to overclaim there.

But the SDK-level failure mode is reproducible under stricter decoder behavior, and this fallback fixes that path while preserving the normal case.