validate MONO_FLAG against channel count in legacy open_file3

[aizu-m]

Built with --enable-legacy, a guard page placed one int past the decode buffer:

WavpackGetNumChannels() = 1
decode 1024 samples into out[1024]  (one channel, 4096 bytes)
fault: write at out+4096

open_file3 takes config.num_channels from the WAV fmt NumChannels field, so the caller sizes its buffer for one channel. unpack_samples3 instead chooses the mono or stereo path from the version 3 header's MONO_FLAG bit. Below version 3 the two agree, because the flags are recomputed from NumChannels a few lines up, but a version 3 file carries its own flags and open_file3 never checks them against NumChannels.

So NumChannels == 1 with MONO_FLAG clear reports one channel yet runs the stereo path, which writes two samples per frame (*bptr++ twice) past the caller's buffer. Found feeding crafted v3 headers to the stand-alone fuzzer: the stereo loop smashes the 1024-int decode buffer on the first WavpackUnpackSamples call (stack-smashing abort under -fstack-protector-all, heap overrun under asan). The inverse, NumChannels == 2 with MONO_FLAG set, only under-writes, but is wrong as well.

Reconciled at the open, matching the pre-3 path. The regression file aborts before the patch and is rejected cleanly after.

[dbry]

Looks good, thanks!