libbladeRF: report RX overruns and leading discontinuities to sync_rx callers

[wormuz]

Two ways an RX gap could reach the caller unreported.

The worker's overrun recovery. sync_worker.c carried a TODO for this: on overrun it resubmits buffers and logs, but nothing propagates the condition. Because recovery restarts the timestamp sequence, the gap is not visible in the message headers either — so bladerf_sync_rx() returns samples that are not contiguous with the previous call, and reports success.

Adds buf_mgmt.overrun_pending, set by the worker and consumed by the next sync_rx(), which now raises BLADERF_META_STATUS_OVERRUN.

A discontinuity landing on the first message of a read. The check in sync_rx() required copied_data, so only gaps found mid-read were flagged; a gap at the start was silently skipped. The status flag is now raised regardless, while the early return stays conditional: with data already copied it must be handed back before the gap, with none copied the read continues past it.

The first header of a stream has nothing to compare against, so meta.have_timestamp distinguishes it from a real discontinuity. It is cleared on init and whenever the stream restarts.

Measured on a bladeRF 2.0 micro xA4 (FX3 2.6.0, FPGA 0.16.0), SC16_Q11_META at 61.44 Msps, host stalled 400 ms between reads to force overruns:

before:   driver logged 141 overruns, meta.status stayed 0x0
after:    2 of 6 reads report BLADERF_META_STATUS_OVERRUN
no stall: 0 of 15 reads report it, driver logs none

Related to #801, which describes the same flag never reaching the caller.

[CLAassistant]

All committers have signed the CLA.