bladerf2: wrap quick tune profile indices instead of running out

[wormuz]

Problem

The Nios quick tune profile counter (quick_tune_rx_profile / quick_tune_tx_profile) only ever increments, and is reset in exactly one place: board initialisation. An application that keeps requesting quick tunes therefore has a hard budget of NUM_BBP_FASTLOCK_PROFILES (256) for the lifetime of the device handle.

Past that, every further bladerf_get_quick_tune() fails:

[ERROR] Reached maximum number of RX quick tune profiles.

and returns BLADERF_ERR_UNEXPECTED, with no way to recover short of closing and reopening the device.

This is easy to hit with a wideband sweep that takes a profile on first visit to each stop: 4700 distinct stops over 70 MHz – 6 GHz exhausts the budget within the first few minutes of operation.

Why wrapping is the right fix

The 256 budget is not a hardware limit on how many retune targets may exist over time. Both the RFIC and the Nios hold caches that this code already overwrites — the RFFE index is assigned modulo NUM_RFFE_FASTLOCK_PROFILES, so profile 8 has always overwritten profile 0.

Letting the Nios index wrap the same way makes the two consistent and keeps long-running sweeps working. Applications that need a stable profile for a specific frequency already have to re-request it, since the RFFE slot underneath may have been reused.

Measured

bladeRF 2.0 micro xA4, FPGA 0.15.0, sweeping 70 MHz – 6 GHz with 4700 distinct stops, taking a quick tune profile on first visit to each:

	before	after
320 stops	counter stuck at 256, every later stop logged the error	320 profiles, no errors
600 stops	—	600 profiles, no errors
3392 stops in 90 s	—	3392 profiles, no errors

The counter is uint16_t and 65536 is a multiple of 256, so wrapping does not disturb the modulo alignment used for the RFFE index.