Eliminate undefined or implementation-defined arithmetic in codec hot paths

[audexdev]

Summary

Several codec paths rely on signed overflow, implementation-defined narrowing, or unchecked shift counts when used with full-range int32_t inputs or malformed streams.

Affected areas

• src/codec/simd/neon.cpp
• src/codec/lac/decoder.cpp
• src/codec/block/encoder.cpp
• src/codec/block/decoder.cpp
• src/codec/rice/rice.cpp
• src/codec/lpc/lpc.cpp

Problem details

Known cases:

• mid/side scalar encode computes l + r and l - r in int32_t
• mid/side decode reconstructs with signed int32_t expressions
• fixed/FIR residual and restore paths narrow unchecked int64_t values to int32_t
• Rice::encode/decode accepts k >= 32, which is invalid for 32-bit shifts
• LPC autocorrelation uses int64_t accumulation while public APIs accept arbitrary int32_t samples

Acceptance criteria

• Use explicit widened arithmetic and range checks where required.
• Reject or clamp malformed decode states consistently according to format rules.
• Add sanitizer-backed tests for boundary values, including full-range int32_t synthetic inputs where applicable.
• Add direct Rice tests for invalid k and k == 31 boundary behavior.

[audexdev]

Partially addressed by #35 (merged):

• Rice::encode now guards the u >> k / 1u << k shifts (k >= 32 was UB; Rice::decode already rejected k > 31).
• ms_encode_scalar_impl computes l+r / l-r in uint32, removing signed-overflow UB while matching the NEON wrapping add/sub bit-for-bit.
• New lac_rice_tests covers round-trip across k, full-range boundary values at the k == 31 shift boundary, and the k > 31 decode rejection. Verified locally under ASan+UBSan and in CI.

Audit of the remaining items: fixed/FIR/LPC residual (block/encoder.cpp) and restore (block/decoder.cpp, lpc.cpp), plus mid/side decode (decoder.cpp, main.cpp), already use int64 accumulation with int32 range checks. LPC autocorrelation is int64 over the validated 16/24-bit domain.

Remaining (keeping this open): optional full-range synthetic-input sanitizer tests exercising the predictor/restore primitives directly (those paths are already range-checked, so this is hardening of the test surface, not a known bug).