Fix bootloader hardware bring-up and add key-based boot entry

Hardware-tested the UF2 bootloader end to end on a real VersaPad v2
board. Found and fixed a real bug: the bootloader's jump into the app
(__set_MSP -> SCB->VTOR -> bx) hard-faulted on every standalone boot,
even with the debugger fully disconnected; identical register/VTOR
values injected directly by a halted debugger ran fine, which pointed
at the missing __DSB()/__ISB() barriers ARM's own guidance requires
for this exact pattern. Also fixed a USB PID collision (0x0011 is
Adafruit's own Gemma M0 bootloader PID, misidentified by Windows as a
Circuit Playground COM port instead of exposing VERSABOOT).

This board has no dedicated reset/boot button, so add a hardware boot
entry that doesn't need one: holding the bottom-right Cherry MX key
(key_id 24) during reset/power-on drives its matrix row and reads its
column directly in the bootloader, before the app is even validated.

Also corrected the app-side flash_with_bootloader.ld (was missing the
NVM carve-out flash_without_bootloader.ld already has) and
boards/versapad.json (wrong flash/RAM size, wrong MCU macro, stale
PID), and enabled the previously-commented-out env:versapad_usb.

Documented findings in bootloader/README.md, bootloader/TESTING.md,
and doc/09_known_limitations.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

boards/versapad.json

@@ -10,9 +10,9 @@
     "extra_flags": "-DARDUINO_SAMD_ZERO -DARM_MATH_CM0PLUS -D__SAMD21G18A__",
     "f_cpu": "48000000L",
     "hwids": [
-      ["0x239A", "0x0011"]
+      ["0x239A", "0x0042"]
     ],
-    "mcu": "samd21g18a",
+    "mcu": "samd21g17d",
     "usb_product": "VersaPad v2",
     "usb_manufacturer": "Custom"
   },
@@ -20,8 +20,8 @@
   "frameworks": ["arduino"],
   "name": "VersaPad v2 (USB bootloader)",
   "upload": {
-    "maximum_ram_size": 32768,
-    "maximum_size": 253952,
+    "maximum_ram_size": 16384,
+    "maximum_size": 120832,
     "disable_flushing": true,
     "native_usb": true,
     "offset": "0x2000",