Support both Nano bootloaders for flashing over WiFi

- Uploader sends 'FLASH <baud>' first; the ESP32 restarts the Nano and
  bridges at that baud rate, then answers OK
- --baud=auto (default) tries 57600 (old ATmegaBOOT) then 115200 (Optiboot)
- Optional nano_reset GPIO (NPN to Nano RESET) pulses reset after power
  on, needed for Optiboot which skips the bootloader after a power cycle
- Clear errors for outdated ESP32 firmware and missing wires
- README: bootloader table, reset wire, troubleshooting

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -17,9 +17,13 @@ See README.md for the overview.
 - If an ESP32 build fails with `No module named 'intelhex'`, run
   `~/.platformio/penv/Scripts/python.exe -m pip install intelhex`.
 - `nano_ota` flashes the Nano over WiFi: `tools/nano_net_upload.py` (STK500v1 over TCP)
-  talks to `NanoFlashBridge` on the ESP32 (port 2323), which power cycles the Nano into
-  its old bootloader (57600 baud) and passes the bytes through. avrdude 6.3's `net:` port is
-  broken on Windows (`ser_drain()` fails), which is why the uploader is a Python script.
+  talks to `NanoFlashBridge` on the ESP32 (port 2323). The uploader first sends
+  `FLASH <baud>\n`. The ESP power cycles the Nano (plus an optional reset pulse on
+  `nano_reset`), answers `OK\n`, then passes the bytes through at that baud rate.
+  `--baud=auto` tries 57600 (old ATmegaBOOT, which also starts after a power cycle), then
+  115200 (Optiboot, which only starts after a reset-pin reset, so it needs `nano_reset`).
+  avrdude 6.3's `net:` port is broken on Windows (`ser_drain()` fails), which is why the
+  uploader is a Python script.
   The uploader only uses the Python standard library. Test it against a simulated
   bootloader before changing it.
 - `src/esp32/libs.h` defines globals in the header, so it can only be included from