Fix FLAC binary seek livelock when byte range collapses - #1145

The deadlock is rare but does happen with some FLAC files.

What changed

• Stop native FLAC binary seeking when its byte range has collapsed to two adjacent offsets.
• Resume from the closest decoded frame before the target and decode forward instead of alternating forever.

Root cause

For a native FLAC without a seek table, seeking to PCM frame 6371359 narrows the binary search to bytes 6242259 and 6242260. Resynchronizing at those offsets finds FLAC frames beginning at PCM 6368256 and 6371712, respectively. The target lies between them, but there is no byte midpoint left and the earlier frame is just beyond the existing two-block forward threshold. The search therefore alternates between the same two offsets indefinitely.

The input is a 16-bit mono 16 kHz FLAC with 10,430,775 samples and no seek table (sha256:907a1d60713ce6e058656b85c827568546a3f1df08105bf8bd43af0036a2edd3). The issue reproduces on current dev with this minimal program:

#include <stdio.h>
#define MINIAUDIO_IMPLEMENTATION
#include "miniaudio.h"

int main(int argc, char** argv)
{
    ma_decoder decoder;
    ma_decoder_config config = ma_decoder_config_init(ma_format_s16, 1, 16000);

    if (argc != 2 || ma_decoder_init_file(argv[1], &config, &decoder) != MA_SUCCESS) {
        return 1;
    }

    puts("seeking");
    return ma_decoder_seek_to_pcm_frame(&decoder, 6371359) == MA_SUCCESS ? 0 : 1;
}

Before this change, the program consumes CPU until externally killed. With this change, the seek returns immediately.

Validation

• Read the requested 361,280-frame segment successfully after the formerly hanging seek.
• Compared 4,096 post-seek samples against brute-force FLAC seeking; all samples matched bit-for-bit.
• Built the library normally and with MINIAUDIO_FORCE_C89=ON; the focused reproducer also completed cleanly under UBSan.

By submitting this pull request, I agree to release this contribution under miniaudio's public-domain/MIT-0 terms.