fix(voice): decode provider PCM16 with explicit little-endian byte order #4816

Summary

StreamedAudioResult._transform_audio_buffer decodes streamed PCM16 bytes with np.frombuffer(..., dtype=np.int16), which uses the host native byte order. The voice pipeline receives PCM bytes, and the repository test helper pcm16_samples explicitly encodes those samples as little-endian (<i2). On a big-endian host, every non-symmetric sample is byte-swapped before it reaches the caller.

This was found while reviewing #4778; it is a separate, pre-existing issue and is not caused by that PR's dtype-spelling change.

Reproduction

For a provider byte stream containing two little-endian PCM16 samples:

raw = b"\x01\x02\x03\x04"
# The provider samples are [0x0201, 0x0403] == [513, 1027].

On a big-endian host, the current np.frombuffer(raw, dtype=np.int16) interpretation is [258, 772] (0x0102, 0x0304) instead. The same wrong samples are used for both np.int16 and np.float32 output.

Relevant implementation: src/agents/voice/result.py. The little-endian test encoding is in src/agents/voice/testing.py.

Expected behavior

Decode provider PCM16 as little-endian on every host, then return the existing native np.int16 or np.float32 output shape. Preserve the current cross-chunk sample-boundary and odd-byte padding behavior.

Root cause

Passing np.int16 to np.frombuffer requests native-endian decoding. The byte stream has a fixed provider encoding, so its byte order must be explicit.

Proposed fix and validation

Use an explicit little-endian i2 decode and normalize the resulting array to native np.int16, with a regression test that simulates a big-endian host and asserts the sample values. I will validate the focused voice tests and the repository's required format, lint, type-check, and test commands in a separate branch.