fix left shift of negative width in legacy get_word3/get_old_word1

[aizu-m]

Turned this up building --enable-legacy under -fsanitize=undefined and decoding mutated version-3 files.

1. get_word3 forms dbits from the bitstream as (ave_dbits>>8) + 1 + delta_dbits, then does ave_dbits[chan] += dbits << 3 before the dbits < 0 guard, so a long run of leading 1-bits leaves dbits negative when it is shifted.
2. get_old_word1 shifts k_value into ave_k the same way, before k_value is range checked.

UBSan reports "left shift of negative value -40" at the get_word3 update on a crafted lossy mono file. The shifted result is only consumed on the error path, so output for valid files is unchanged. Cast the operand to uint32_t before the shift, matching the min_value/max_value shifts already in unpack_samples3. Added a regression file under fuzzing/regression/.

[dbry]

Thanks for this, but I think a cleaner fix would be to replace the left-shift of 3 with a multiply by 8. It's not ugly like the cast and optimizing compilers are going to generate the same code anyway. What do you think?