fkclaude: prepare two more upstream PRs, neither submitted

Both are staged for review before anything is sent.

ci-node24-actions, for oltaco's bootloader repo: the four-line workflow bump onto actions that
declare node24. Already proven by running a release on the fork - 14 boards, 42 assets, and the
"Node 20 is deprecated" annotation gone from every job.

adafruit-touch2400-uf2, for adafruit/Adafruit_TinyUSB_Arduino: rather than changing what touch 1200
means, this adds touch 2400 as a request for the bootloader's mass storage mode, with a weak default
so no port is obliged to implement it and touch 1200 is untouched everywhere. The description argues
the case in full, including why flipping TinyUSB_Port_EnterDFU() was tried and rejected, the measured
fact that MSC does not interfere with a serial DFU transfer, and the one hazard of the chosen baud
rate with two alternatives offered. It states plainly that the 2400 path itself has not yet been run
on hardware.

Author: fkallay1

fkclaude/docs/upstream-prs/adafruit-touch2400-uf2.diff

@@ -0,0 +1,65 @@
+diff --git a/src/arduino/Adafruit_TinyUSB_API.cpp b/src/arduino/Adafruit_TinyUSB_API.cpp
+index 2f27632..f8c7d72 100644
+--- a/src/arduino/Adafruit_TinyUSB_API.cpp
++++ b/src/arduino/Adafruit_TinyUSB_API.cpp
+@@ -33,6 +33,12 @@ extern "C" {
+ 
+ uint32_t tusb_time_millis_api(void) { return millis(); }
+ 
++// Ports whose bootloader has no separate mass storage mode fall back to the plain DFU
++// entry, so touch 2400 degrades to exactly what touch 1200 already does there.
++__attribute__((weak)) void TinyUSB_Port_EnterMassStorageDFU(void) {
++  TinyUSB_Port_EnterDFU();
++}
++
+ //--------------------------------------------------------------------+
+ // Device
+ //--------------------------------------------------------------------+
+diff --git a/src/arduino/Adafruit_TinyUSB_API.h b/src/arduino/Adafruit_TinyUSB_API.h
+index 77826a6..f3bf6b4 100644
+--- a/src/arduino/Adafruit_TinyUSB_API.h
++++ b/src/arduino/Adafruit_TinyUSB_API.h
+@@ -82,6 +82,13 @@ void TinyUSB_Device_FlushCDC(void) __attribute__((weak));
+ // usually when host disconnects cdc at baud 1200 (touch 1200)
+ void TinyUSB_Port_EnterDFU(void);
+ 
++// To enter/reboot to the bootloader's mass storage (UF2) mode, for ports whose
++// bootloader has one distinct from the plain DFU entry above.
++// Invoked when host disconnects cdc at baud 2400 (touch 2400).
++// Optional: a weak default forwards to TinyUSB_Port_EnterDFU(), so a port without a
++// separate mass storage mode behaves exactly as it does today and need not implement it.
++void TinyUSB_Port_EnterMassStorageDFU(void);
++
+ // Init device hardware.
+ // Called by TinyUSB_Device_Init()
+ void TinyUSB_Port_InitDevice(uint8_t rhport);
+diff --git a/src/arduino/Adafruit_USBD_CDC.cpp b/src/arduino/Adafruit_USBD_CDC.cpp
+index 11c5673..0fb8cc2 100644
+--- a/src/arduino/Adafruit_USBD_CDC.cpp
++++ b/src/arduino/Adafruit_USBD_CDC.cpp
+@@ -280,6 +280,8 @@ void tud_cdc_line_state_cb(uint8_t instance, bool dtr, bool rts) {
+ 
+       if (coding.bit_rate == 1200) {
+         TinyUSB_Port_EnterDFU();
++      } else if (coding.bit_rate == 2400) {
++        TinyUSB_Port_EnterMassStorageDFU();
+       }
+     }
+   }
+diff --git a/src/arduino/ports/nrf/Adafruit_TinyUSB_nrf.cpp b/src/arduino/ports/nrf/Adafruit_TinyUSB_nrf.cpp
+index a5558b8..83a779f 100644
+--- a/src/arduino/ports/nrf/Adafruit_TinyUSB_nrf.cpp
++++ b/src/arduino/ports/nrf/Adafruit_TinyUSB_nrf.cpp
+@@ -97,6 +97,12 @@ void TinyUSB_Port_EnterDFU(void) {
+   enterSerialDfu();
+ }
+ 
++void TinyUSB_Port_EnterMassStorageDFU(void) {
++  // Reset to the bootloader with mass storage exposed, so a host can drop in a .uf2.
++  // Both modes keep CDC, so serial DFU still works either way - this only adds the drive.
++  enterUf2Dfu();
++}
++
+ uint8_t TinyUSB_Port_GetSerialNumber(uint8_t serial_id[16]) {
+   uint32_t *serial_32 = (uint32_t *)serial_id;
+ 

fkclaude/docs/upstream-prs/adafruit-touch2400-uf2.msg.md

@@ -0,0 +1,87 @@
+Add touch 2400 to request the bootloader's mass storage (UF2) mode
+
+**Target:** `adafruit/Adafruit_TinyUSB_Arduino`, base `master`
+**Branch:** `feature/touch2400-enter-uf2-dfu` — 4 files, +21/−0, no deletions
+**Status:** prepared, not submitted. Not yet verified on hardware (see the last section).
+
+## The problem
+
+A host that cannot reach the board physically has no way to ask for the mass storage side of the
+bootloader. Touch 1200 is the only remote trigger this library exposes, and on nRF52 it lands in
+serial-only DFU (CDC) — never the UF2 drive (CDC + MSC).
+
+That gap has a concrete consequence: **UF2 is the only route that can carry a bootloader update.** A
+DFU zip cannot, because that path requires an application manifest. So a remotely deployed nRF52
+node — in our case reached over a USB/IP bridge, with nobody near the board — can have its
+application updated but never its bootloader, purely because the mass storage mode is unreachable
+without a physical double tap.
+
+## What this changes
+
+Three small additions and one nRF52 implementation:
+
+- `TinyUSB_Port_EnterMassStorageDFU()`, a new **optional** port hook, invoked when the host
+  disconnects CDC at **2400** baud.
+- A **weak default** forwarding it to `TinyUSB_Port_EnterDFU()`. This follows the pattern already
+  used in the same header for `TinyUSB_Device_Init`, `TinyUSB_Device_Task` and
+  `TinyUSB_Device_FlushCDC`, so it is not a new mechanism here.
+- The nRF52 port implements it with `enterUf2Dfu()`, which the core already provides right next to
+  `enterSerialDfu()` in `wiring.h`. Nothing new is invented; an existing entry point is exposed.
+
+**Touch 1200 is not modified on any port.** Existing tools, the Arduino/PlatformIO upload path, and
+every board's current behaviour are untouched. Ports whose bootloader has no distinct mass storage
+mode need no change at all — the weak default makes touch 2400 degrade to exactly what touch 1200
+already does there. Of the five ports in the tree, only `nrf` gains a distinct behaviour:
+
+| port | `EnterDFU` | overrides the new hook |
+|---|---|---|
+| nrf | yes | **yes** — `enterUf2Dfu()` |
+| rp2040, samd, ch32, esp32 | yes | no — falls back via the weak default |
+
+## Why not simply change what touch 1200 does
+
+That was the first thing we tried, as a local patch: make `TinyUSB_Port_EnterDFU()` call
+`enterUf2Dfu()`. It works, and we rejected it for two reasons.
+
+**It changes the normal upload path for everybody.** The 1200-baud touch *is* how the IDE uploads, so
+every upload on every sketch built with the core would start mounting a removable drive. On Windows
+that means a drive letter, an Explorer window, and an indexer or antivirus scanning a freshly
+appeared FAT volume — while a serial DFU transfer is in flight. Nuisance at best, and not something
+to inflict on users who never asked for it.
+
+**It removes the choice.** With a second baud rate the *host* decides, per touch, which mode it wants.
+Nothing has to be rebuilt to switch intent, and a tool that only knows 1200 keeps working.
+
+For completeness, we also measured whether the mass storage interface interferes with a serial DFU
+transfer, since that would have been the stronger objection to either approach: it does not. A full
+serial DFU flash completed normally with MSC mounted — 28.33 s, 928 progress marks, `Device
+programmed.` on an nRF52840 already in UF2 mode. So the argument against changing the default is
+about nuisance, not breakage.
+
+## The choice of 2400, and its one hazard
+
+2400 is proposed because it is archaic enough to be unused for real data, which is the same reason
+1200 was chosen. The hazard is the same one 1200 already has: **open a serial monitor at 2400 baud
+and close it, and the device reboots into UF2 mode.** Recoverable (a reset returns to the
+application) but surprising.
+
+If you would rather avoid that, the patch is trivially adaptable and we have no attachment to the
+value:
+
+- a different rate, or a deliberately odd one such as 1201, which no terminal offers by default;
+- or gate the whole thing behind a build flag, so only firmware that wants it responds at all.
+
+Say which you prefer and it will be changed — the mechanism is the point, not the number.
+
+## What is and is not verified
+
+Verified: the patch applies cleanly to `master`, the weak-default pattern matches existing usage in
+the same header, and `enterUf2Dfu()` is already declared in the nRF52 core's public `wiring.h`
+alongside `enterSerialDfu()`, so the nRF52 implementation compiles against what the core already
+exposes.
+
+The 2400 path has **not** yet been exercised on hardware. What has been measured, on an nRF52840
+ProMicro and a XIAO nRF52840 Sense, is the behaviour on both sides of it: a 1200-baud touch reaching
+serial-only DFU (CDC, no mass storage), and a device in UF2 mode (CDC + MSC) accepting a full serial
+DFU flash. Happy to run the 2400 path on both boards before you spend time on this — say so and the
+result will be posted here.

fkclaude/docs/upstream-prs/ci-node24-actions.diff

@@ -0,0 +1,38 @@
+diff --git a/.github/workflows/githubci.yml b/.github/workflows/githubci.yml
+index c65812b..ff60858 100644
+--- a/.github/workflows/githubci.yml
++++ b/.github/workflows/githubci.yml
+@@ -15,7 +15,7 @@ jobs:
+       matrix: ${{ steps.set-matrix.outputs.matrix }}
+     steps:
+       - name: Checkout Code
+-        uses: actions/checkout@v4
++        uses: actions/checkout@v7
+ 
+       - name: Set matrix
+         id: set-matrix
+@@ -34,7 +34,7 @@ jobs:
+         board: ${{ fromJSON(needs.set-matrix.outputs.matrix) }}
+     steps:
+     - name: Checkout Code
+-      uses: actions/checkout@v4
++      uses: actions/checkout@v7
+       with:
+         fetch-depth: 0
+         submodules: true
+@@ -53,13 +53,13 @@ jobs:
+         make BOARD=${{ matrix.board }} all
+         make BOARD=${{ matrix.board }} copy-artifact
+ 
+-    - uses: actions/upload-artifact@v4
++    - uses: actions/upload-artifact@v7
+       with:
+         name: ${{ matrix.board }}
+         path: _bin/${{ matrix.board }}
+ 
+     - name: Upload Release Asset
+-      uses: softprops/action-gh-release@v1
++      uses: softprops/action-gh-release@v3
+       if: ${{ github.event_name == 'release' }}
+       with:
+         files: |

fkclaude/docs/upstream-prs/ci-node24-actions.msg.md

@@ -0,0 +1,16 @@
+ci: move the release build onto actions that target Node 24
+
+Every job in the last release build carries the same warning: checkout@v4 and upload-artifact@v4
+declare node20 and action-gh-release@v1 declares node16, so the runner is forcing all three onto
+Node 24. That fallback works today, but when it is withdrawn - as it was for Node 12 and Node 16 -
+the steps will not start at all. Since the push and pull_request triggers are commented out, the
+first sign of it would be a release that produces no assets.
+
+Bumped to the current majors that declare node24: checkout v7, upload-artifact v7,
+action-gh-release v3. Worth knowing that the Node version does not track the major cleanly -
+upload-artifact v5 is still node20, so v6 is the first that helps. Every input this workflow relies
+on (name, path, fetch-depth, submodules, files) exists unchanged in those majors.
+
+Tested by running a release on a fork: all 14 boards built and all 42 assets were attached, and the
+"Node 20 is deprecated" annotation is gone from every job.
+