fix: decode base64 embeddings as little-endian floats - #3711

• I understand that this repository is auto-generated and my pull request may not be merged

Root cause

The base64 embedding representation contains little-endian float32 bytes, but the handwritten response parser used native byte order in both its NumPy and stdlib paths. On big-endian Python platforms, that silently produces incorrect vector values. The existing fixture was also native-endian, so it followed the test host instead of the wire format and could not expose the defect.

Fix

• Decode the NumPy path with the explicit <f4 dtype.
• Byte-swap the stdlib array("f") path on big-endian hosts.
• Construct fixture bytes with struct.pack("<3f", ...) so the test represents the wire format on every host.
• Cover the stdlib big-endian branch without requiring big-endian CI hardware.

The branch is rebased onto current main and preserves #3757: NumPy availability is still checked once per response, while each encoded vector is decoded only once.

Validation

Before the rebase, the focused embeddings suite passed under both Pydantic environments (58 tests each), along with targeted Ruff, Pyright, and Mypy checks. After rebasing onto #3757, I re-ran syntax checks and an isolated execution harness against the actual parser module covering:

• stdlib little-endian decoding for multiple vectors
• simulated stdlib big-endian byte swapping
• NumPy decoding with the explicit <f4 dtype
• one NumPy availability check per response

The full current suite is left to GitHub Actions because this local macOS workspace does not have the repository's locked uv development environment installed.