fkclaude: prefer an application command over patching the core's touch handler

enterUf2Dfu() is declared in the core's public cores/nRF5/wiring.h, so an application can call it
directly - a MeshCore command "reboot to UF2" needs no core change at all. That is strictly better
than patching TinyUSB_Port_EnterDFU(), which changes what a 1200-baud touch means for every
application built on that core; since the touch is the normal Arduino upload path, on Windows a
removable drive would appear on every upload, with an indexer or antivirus scanning a freshly mounted
FAT volume while a serial DFU is in flight.

Recorded the measurement that argument needs: serial DFU does work with MSC mounted - the XIAO was
flashed from UF2 mode in 28.33 s, 928 marks, Device programmed. So MSC is a nuisance there, not a
breakage.

Also corrected an overstatement from the previous note. meshcore-dev/MeshCore is as much an upstream
as oltaco's bootloader; a command added there needs its own PR. The asymmetry that survives is the
cost of carrying the change until it lands - the command sits in a fork already maintained and built
from, while the core patch would need a fork of meshcore-dev/Adafruit_nRF52_Arduino and a re-pinned
platformio.ini, or PlatformIO overwrites it.

And the three routes are not redundant: an application command covers a running application, PR 47's
recovery covers an invalid one, and only PR 50 covers a bootloader already sitting in serial-only DFU.

Author: fkallay1

fkclaude/fcl_readme_dfu_recovery.md

@@ -149,6 +149,37 @@ separate problems - the patch only solves the first.
 Currently **not applied** anywhere, confirmed by measurement: a 1200-baud touch on the XIAO brings up
 CDC with no mass storage, i.e. the unpatched `enterSerialDfu()`.
 
+### A third route, which is better than the patch
+
+`enterUf2Dfu()` is declared in the core's **public** header `cores/nRF5/wiring.h`, next to
+`enterSerialDfu()` and `enterOTADfu()`. So the **application can call it itself** - a MeshCore command
+"reboot to UF2" needs no core change at all.
+
+That is strictly better than patching `TinyUSB_Port_EnterDFU()`. The patch changes what a 1200-baud
+touch means for every application built on that core, and since the touch *is* the normal Arduino
+upload path, on Windows a removable drive would appear on **every upload** - drive letter, Explorer,
+and an indexer or antivirus scanning a freshly mounted FAT volume exactly while a serial DFU is in
+flight. That is the first objection a maintainer would raise, and it is a fair one.
+
+Worth knowing for that argument: serial DFU **does** work with MSC mounted. The XIAO was flashed from
+UF2 mode (`PID_0045` + mass storage) in 28.33 s, 928 marks, `Device programmed.` - so MSC is a
+nuisance here, not a breakage.
+
+Neither route makes the others redundant, because the three device states do not overlap:
+
+| device state | what reaches UF2 mode |
+|---|---|
+| application running | a MeshCore command calling `enterUf2Dfu()` |
+| application invalid, or a transfer was interrupted | recovery (PR #47) comes up CDC + MSC by itself |
+| bootloader already sitting in serial-only DFU | **only `DFU_REBOOT_PACKET` (PR #50)**, else a physical double tap |
+
+One caution against over-optimism: `meshcore-dev/MeshCore` is as much an upstream as
+`oltaco/…Bootloader` - a command added there needs its own PR and its own maintainer's agreement. The
+difference is not the upstream, it is the cost of carrying the change until it lands: the command sits
+in the MeshCore fork that is already maintained and built from, whereas the core patch would mean
+forking `meshcore-dev/Adafruit_nRF52_Arduino` and re-pinning `platformio.ini` - or being overwritten
+by PlatformIO on the next framework reinstall.
+
 ## Verification
 
 All on a ProMicro nRF52840 + J-Link, verdicts read from the device (`bank_0` over SWD), never