Fix SIGSEGV in Highway kernels: use unaligned Load/Store on std::vector-backed blobs

[pszemus]

Summary

The highway/ module crashes with SIGSEGV on any x86 target ≥ AVX2 (e.g.
building with -march=skylake, -march=haswell, -march=cascadelake). Five
elementwise kernels in src/hw_kernels_hw.cpp use Highway's aligned
Load/Store on blob data that is only std::vector<float>-aligned, which is
narrower than the SIMD vector width.

Symptom

fdt::hw::AddHw hw_kernels_hw.cpp:65
... (any pipeline that calls AddHw / DotProductHw / ReluHw / MulAddHw / AddInplaceHw)

SIGSEGV inside hn::Store(hn::Add(hn::Load(...), hn::Load(...)), ...).

Root cause

• Blob storage is HwBlob::data_, a std::vector<float>. Its base pointer is
  only aligned to the default allocator alignment (16 bytes on x86-64 glibc),
  not the SIMD vector width.
• Highway's Load/Store are the aligned variants and require the pointer to
  be aligned to the vector size — 32 bytes for AVX2, 64 bytes for AVX-512.
• On an SSE target (128-bit, 16-byte alignment) the 16-byte base happens to
  satisfy the requirement, so it works. On AVX2+ the aligned move (vmovaps)
  hits a 16-byte-but-not-32-byte address → #GP → SIGSEGV.
• Channel padding (PaddedChannels) makes per-pixel Ptr() offsets a multiple
  of the vector size, but the base data_.data() is still only 16-byte
  aligned, so it does not help.

This is an inconsistency within the file itself: the other ~150 load/store sites
already use the unaligned LoadU/StoreU. Only these 5 functions use the
aligned variant: MulAddLoop, DotProductHw, AddHw, AddInplaceHw, ReluHw.

[pszemus]

@ShiqiYu @Wwupup can you guys please look at this?

[Wwupup]

@ShiqiYu @Wwupup can you guys please look at this?

thank you very much for both PRs — and my sincere apologies for the long delay in responding. I’ve been away from the project for the past week and didn’t get a chance to look at these earlier. I’ll review the code in detail within the next 24–48 hours and will either merge or leave any minor comments. Please bear with me just a little longer.

Thanks again for your patience and your excellent contribution!