fix: isolate the 0x8820 loader profile per USB device

Derive the FMAC-only profile from each device readback instead of a module-global latch. A regular D80 must still load its patches after another adapter reports product 0x8820. Reject a busy connect with EBUSY without resetting the state of an operation already in flight.

Extracted-function tests cover alternating devices, reprobe, cache setup, configuration errors and unchanged busy states. All three modules build against Linux 6.17 headers. Hardware retest of this revision and Bluetooth remain pending.

tests/issue119-8820/README.md

@@ -0,0 +1,16 @@
+# Product 0x8820 loader checks
+
+Run `python3 tests/issue119-8820/test_loader.py` with a C compiler available.
+The test extracts the actual system configuration, normal-mode upload branch,
+and busy-connect guard and runs them against mocked USB requests. It checks
+that alternating/reprobing M80 and regular D80 devices preserves each loader
+sequence, retains the MCU1 cache fix, propagates configuration errors, and
+rejects a new connect without overwriting an operation already in progress.
+
+These checks do not establish hardware or Bluetooth compatibility. Issue #118
+reports working Wi-Fi on one UGREEN `a69c:5723`, chip revision 7, MCU1 unit
+with product `0x8820` and the branch's 327,037-byte V3 FMAC. Bluetooth pairing
+and audio remain unverified. Product `0x8820` is not a rule to skip patches
+on every MCU1 device, and the report does not establish that every device in
+issue #79 works with this firmware.
+