Address x86 SIMD gap, misleading neon_available(), and unguarded endianness

[audexdev]

Summary

SIMD acceleration is ARM-NEON only, "availability" is a compile-time constant masquerading as a runtime probe, and host little-endianness is assumed without any guard. On x86 (or any non-NEON target) every accelerated path silently falls back to scalar, and the empty endian.hpp advertises a portability layer that does not exist.

Affected areas

• src/codec/simd/neon.hpp / src/codec/simd/neon.cpp
• src/utils/endian.hpp

Problem details

• No x86 SIMD. There is no SSE/AVX implementation anywhere; all acceleration is gated on #if defined(__ARM_NEON). For a codec presented as optimized, this is an undocumented platform gap.
• neon_available() is misleading. It returns the constexpr kHasNeon (neon.cpp:264-266), so it can never report a build/runtime mismatch and is not the runtime CPU probe its name implies.
• Endianness assumed, not enforced. WAV I/O assembles multi-byte values byte-by-byte (endian-safe), but the NEON kernels (vld1q_s32 over int32_t*) and the bitstream layer implicitly assume host byte order. endian.hpp is empty (0 bytes), and there is no static_assert(std::endian::native == std::endian::little) or equivalent anywhere, so a big-endian build would diverge silently.

Acceptance criteria

• Either add an x86 SIMD path (SSE/AVX) for the hot kernels, or explicitly document that SIMD acceleration is ARM-only and x86 uses the scalar path.
• neon_available() either performs a real runtime check or is renamed/removed so it does not imply runtime detection.
• Host endianness is explicitly asserted (compile-time) or handled, and endian.hpp is either implemented or removed.
• Any SIMD/scalar selection remains bit-identical (see the SIMD bit-exactness issue).