to_typed_array_spec encodes bdata in host byte order; plotly.js always decodes it as little-endian #5837

Summary

to_typed_array_spec (_plotly_utils/utils.py:84) does:

arrObj = {
    "dtype": plotlyjsShortTypes[dtype],
    "bdata": base64.b64encode(v).decode("ascii"),
}

with no explicit byte-order normalization before encoding, so bdata follows whatever byte order the array's dtype naturally has, which for an array built without an explicit </> prefix is the host's native order.

plotly.js decodes bdata with new Float64Array(buffer), which always reads in the platform's native order, little-endian in every real browser. On a big-endian host, this means bdata ships bytes that no browser can read correctly.

Repro (confirmed on real big-endian hardware: z/OS/s390x, numpy 2.5.3)

Through the actual function, not just a standalone simulation:

import numpy as np
from _plotly_utils.utils import to_typed_array_spec

v = np.array([1.1, 2.3, 3.5])
spec = to_typed_array_spec(v)
print(spec)

import base64
raw = base64.b64decode(spec["bdata"])
as_little = np.frombuffer(raw, dtype="<f8")  # what plotly.js's Float64Array reads
print("decoded as browser Float64Array would read it:", as_little)
print("matches original:", np.array_equal(v, as_little))

Output:

{'dtype': 'f8', 'bdata': 'P/GZmZmZmZpAAmZmZmZmZkAMAAAAAAAA'}
decoded as browser Float64Array would read it: [-1.54234871e-180  1.90359857e+185  1.54938987e-320]
matches original: False

So any big-endian host produces charts with silently corrupted numeric data.

Suggested fix

Normalize v to little-endian before encoding, e.g. v = v.astype(v.dtype.newbyteorder("<")) immediately before the base64.b64encode(v) call. Verified this resolves it on the same hardware:

v_fixed = v.astype(v.dtype.newbyteorder("<"))
bdata_fixed = base64.b64encode(v_fixed).decode("ascii")
raw_fixed = base64.b64decode(bdata_fixed)
as_little_fixed = np.frombuffer(raw_fixed, dtype="<f8")
print(np.array_equal(v, as_little_fixed))  # True

Originally spotted by @chrikrah in #5833;