[cjacoby-sptfy]

Problem

A finite, seekable WAV can declare more audio data than physically exists.
For example, a 100 ms stereo PCM16 file at 48 kHz with a data size of
0xFFFFFFFF reports over six hours of audio. This can cause oversized buffer
allocations and resampling or writing of silence past physical EOF.

We discovered this while ingesting a new dataset which had a couple of files
with malformed wav headers.

Solution

Locate the audio JUCE selects and calculate how many complete frames fit
between its start and physical EOF. Use JUCE's decoding rules for frame
size, then lower its reported frame count only when it exceeds that limit.

Keep existing format acceptance and codec selection. Add regression tests
for supported PCM/float32 WAV and RF64 layouts, plus compatibility checks
against 0.9.26. A version guard flags future JUCE upgrades for review.

Result

For supported inputs, overstated lengths no longer make reads or resampling
continue through nonexistent audio. Shorter declarations and unrelated
decoder behavior stay as before.

Recovery needs a known stream length and an identifiable audio layout. It
cannot distinguish audio from trailing metadata swallowed by an oversized
data chunk, so those bytes can still be decoded as audio.

Local validation on macOS arm64:

• 286 WAV cases pass. The full suite reports 27,215 passes, 4 skips and one
  previously observed threading-performance failure.
• CI-pinned type checking, formatting and diff checks pass. The docs build
  has the same 17 existing diagnostics. Cross-platform checks run in CI.

[bushaev]

LGTM