main is RED on sanitize-cpu: Ltx2LoadVaeWeights reinterpret_casts unaligned safetensors bytes to const uint16_t* (third recurrence of the class)

[localai-bot]

main is RED on the sanitize-cpu (address,undefined) lane, and has been since
cefacd2d0 (#641, the LTX-2.5 landing). The newest baseline run
31724380111
(job 94529001928) reports exactly one failing test, with exactly one finding:

30/423 Test  #30: test_ltx2_video .............................................***Failed    1.41 sec
src/vllm/model_executor/models/ltx2_loader.cpp:1288:91: runtime error:
load of misaligned address 0x7f3c895be129 for type 'const uint16_t',
which requires 2 byte alignment

:1288 at cefacd2d0 is Ltx2LoadVaeWeights's bf16 arm (:1325 on today's
main, the file has since shifted):

const uint16_t* src = reinterpret_cast<const uint16_t*>(t.data);
for (int64_t i = 0; i < numel; ++i) values[static_cast<size_t>(i)] = Bf16ToF32(src[i]);

StTensor::data points into the read-only safetensors mmap
(safetensors_reader.h:16-23). Safetensors guarantees no alignment for a
tensor's data offset: the payload starts immediately after a JSON header of
arbitrary length, and each tensor's offset is the running sum of its
predecessors' sizes, so a bf16 tensor that follows an odd-length one (or any
tensor at all, when the header length makes the payload base odd) begins on an
odd byte. Forming and dereferencing a const uint16_t* there is UB regardless of
what x86 tolerates, and it is a genuine fault on the strict-alignment targets
this project builds and ships for — build-test-cpu-arm64, Jetson/Orin
(BACKEND-CUDA-SM110), and the Thor lane.

This is the third recurrence of one bug class, which is the part worth
recording:

	site	outcome
#301	cpu_ops.cpp:33, laguna.cpp:1028, test_load_direct_upload.cpp:177	CLOSED — fixed, and produced the shared seam vt::LoadUnaligned<T> (include/vt/unaligned.h)
#627	qwen3_5_weights.cpp:332 (TransposeBf16)	OPEN — not currently firing; that fixture's offsets happen to land even
this one	ltx2_loader.cpp:1325 (Ltx2LoadVaeWeights)	RED on main now

A fourth site already carries the correct treatment and the reason in prose —
minimax_h3_vae_loader.cpp:87-101 explicitly says "Byte-wise load, NOT
reinterpret_cast<const uint16_t*>(tensor.data)[i]" and cites the same UBSan
message. So the knowledge exists in-tree at three places and the new loader still
reached main with the cast; nothing gates the pattern.

Repair: read through the shared seam, vt::LoadUnaligned<uint16_t>, which is
a std::memcpy and compiles to the same single load where the address does
happen to be aligned. Not a cast, not a pragma, not a suppression.

Regression coverage owed: test_ltx2_video only caught this by accident —
the fixture's JSON header happens to make that tensor's offset odd today, and any
edit to a fixture name or shape can silently make it even again and retire the
coverage. The fix owes a test that deliberately pins an odd payload offset and
asserts the pointer parity it depends on, so the guarantee cannot stop being
tested without the test failing.

Scope of this issue: the ltx2_loader.cpp site and its regression test. The
qwen3_5_weights.cpp site and the wider sweep stay with #627, which asks for
27B/35B/Coder golden-md5 inertness evidence this repair cannot produce (no GPU).