Add DdD firmware 3.1 capture support

[JunliangRen]

Summary

This adds support for the DdD protocol-v1 firmware family introduced in firmware 3.1, while keeping legacy DdD and non-DdD devices on their existing paths.

• Legacy DdD continues to use the existing backend.
• Protocol-v1 DdD uses the new control and asynchronous USB path.
• Device indices remain profile-local, and protocol-v1 reconnects use the USB topology path.
• Unsupported future protocol revisions are detected but not assumed compatible.
• Builds without DdD support retain their existing behaviour.

Sample rate handling

For protocol-v1 DdD, the existing RF sample-rate selector is now the only rate control:

• 40 MSPS (HW): native full-rate capture, without software resampling.
• 20 MSPS (HW): FPGA 2:1 decimation, without software resampling.
• Below 20 MSPS (SW): capture at 20 MSPS in hardware, then use the existing software resampler for the selected output rate.

The selector shows whether the current path is hardware or software, including the hardware source rate for resampled output. Existing saved protocol-v1 settings retain their effective output rate.

This policy applies only to protocol-v1 DdD. Legacy DdD and other capture devices keep their existing controls and behaviour.

Capture safety

Protocol-v1 startup validates the device identity, register-map version and image role. Test mode and decimation are written and read back before collection starts, and collection is explicitly bracketed with the B5 start/stop request.

Partial startup failures roll the device back to safe defaults. The asynchronous USB path uses a bounded 96 x 128 KiB queue, consumes transfers in submission order, and stops on short transfers, sequence errors or callback failures rather than continuing with potentially corrupted data. Recovery messages distinguish device/path locks that require a replug from unreaped-callback quarantine that requires restarting MISRC.

Validation

• Windows MinGW build and launch smoke test passed.
• Linux build passed.
• All three Meson test targets passed on Windows and Linux.
• Unit coverage includes profile classification, rate routing, existing-setting compatibility, endpoint selection, startup/readback/rollback, sequence validation, asynchronous ordering and injected failure paths.
• Bounded tests with real firmware 3.1 hardware passed at both 20 and 40 MSPS:
  • identity and register readback
  • B5 start/stop lifecycle
  • 8 MiB discard followed by 1 MiB strict sequence validation
• A bounded 17.9 MSPS output capture was also exercised end to end using the 20 MSPS hardware path followed by the existing software resampler.

A later extended diagnostic run, after prior capture failures and without a physical replug, encountered a raw sequence discontinuity before resampling. A clean power-cycle soak retest is still pending, so this PR does not claim sustained long-run hardware validation.

Screenshots

Protocol-v1 device detection

The protocol-v1 device uses the concise DdD name, while legacy DdD keeps its legacy suffix and other device entries remain unchanged.

20 MSPS hardware path

The unified RF selector marks 20 MSPS as a hardware path using the FPGA's 2:1 decimation.

17.9 MSPS software path

Below 20 MSPS, the selector shows that the requested output is produced by software resampling from the 20 MSPS hardware stream.

[harrypm]

Just to note the GUI can do 1/2 and 1/4 scale for single channel examples much cleaner as there is not a 2nd channel of info to work with and or take up resolution for example snips.

[harrypm]

I would also just make update the resample box to use hardware rate for 20msps, this keeps the UI a bit more compact and it is redundant otherwise an hard/soft subtext can explain it when selected the status bar can provide a message.

[JunliangRen]

Thanks, I've updated this. For protocol-v1 DdD, the existing RF rate selector is now the only rate control. 40 and 20 MSPS use the hardware paths, while lower rates capture at 20 MSPS and use the existing software resampler. The selector and status bar indicate whether the active path is HW or SW, including the hardware source rate. Legacy DdD and other devices remain unchanged. I've also updated the PR screenshots.

[harrypm]

Aside from the "Output A" naming should just be RF ChA / RF ChB tbh.

I think this is looking solid.

[harrypm]

Also looking at the added DdD info, now that should be kept simple on the readme and collapsed into the setup notes most causal users won't be really migrating to the new firmware anywho.

[JunliangRen]

Fair point - I agree. Although by then, the 'new' firmware may be the first firmware DdD newcomers ever meet! Either way, I've kept the supported hardware list simple and moved the short compatibility note into a collapsed DdD setup section (9b33fe4).

[harrypm]

Okay this looks good to merge and let users find any snags!