esp32: don't cap flash baud rate once the stub loader is running

[flrossetto]

MaxUARTFlashBaud (230400 on classic ESP32) exists because the ROM bootloader disables interrupts during flash page writes, which can overrun a USB-UART bridge's small RX FIFO. Once the stub loader is running it buffers incoming data itself and doesn't have this problem — confirmed against real esptool.py on the same board/bridge, which raises the baud rate freely once its stub is up (921600 ran clean). The cap was being applied unconditionally, silently overriding any higher FlashBaudRate even in stub mode.

Also fix detectChip's ESP32-S2 fallback: it treated any readReg failure (timeout, garbled response, checksum error) as proof the chip doesn't support register reads and is therefore ESP32-S2 in secure download mode. Real esptool.py only draws that conclusion from a genuine UnsupportedCommandError NAK. On flaky UART-bridge hardware, a plain communication hiccup was enough to misdetect a real ESP32 as ESP32-S2, load the wrong stub, and fail with a confusing "erase requires stub" error instead of a clear connection error. Now only a CommandError with status 0xFF (command not implemented) triggers the ESP32-S2 fallback; anything else surfaces as a real, retryable error.

[deadprogram]

Hello @flrossetto please see test failures. Also please see the newly added AGENTS.md for guidelines. Thanks.