fix(mesh): DTR/RTS reset settle time was far shorter than real boot time

Every one of Reticulum/Meshcore/Meshtastic's open() deasserts DTR/RTS on
every connection attempt (needed to clear stale line state, but the
transition itself resets ESP32-S3 native-USB boards and CP2102/CH340-
bridged boards wired for Arduino-style auto-reset — acknowledged in the
existing code comments). Each only waited 300ms before expecting a
handshake response — nowhere near real firmware boot time (LoRa radio
init alone routinely takes longer).

A single auto-detect cycle tries multiple protocols in sequence
(Reticulum, then Meshcore, then Meshtastic), each with its own open() and
thus its own reset. With only 300ms of settle per attempt, a board could
plausibly never finish booting from one attempt's reset before the next
attempt's open() reset it again — a self-sustaining "never finishes
booting" loop that would look identical to firmware/hardware flakiness
from the logs, regardless of which firmware family was actually flashed.
Confirmed live 2026-07-23 on both a Heltec V3 (Meshtastic) and V4
(Meshcore): continuous device-side FROM_RADIO_REBOOTED / boot-loop
symptoms with zero config-write-triggered reboots (manage_radio was false
for part of the test), pointing at the connection layer itself rather
than firmware config provisioning.

Bumped the settle delay from 300ms to 2s in Meshcore's and Meshtastic's
open() — full protocol handshakes that need real boot time. Left
reticulum.rs's probe_rnode settle at 300ms deliberately: it's a
cheap/fast KISS-detect gate designed to fail quickly for non-RNode
firmware (documented elsewhere as "~1s"), not a full handshake, and each
subsequent protocol's own open()+settle is what actually needs to cover
real boot time regardless of what probe_rnode did moments before.

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

core/archipelago/src/mesh/meshtastic.rs

@@ -214,11 +214,20 @@ impl MeshtasticDevice {
             path
         ))?;
         // See probe_rnode() in reticulum.rs for why: ESP32-S3 native-USB
-        // boards reset on a DTR/RTS transition, so deassert both and settle
+        // boards (and CP2102/CH340-bridged boards wired for Arduino-style
-        // before the handshake below.
+        // auto-reset) reset on a DTR/RTS transition, so deassert both and
+        // settle before the handshake below. 300ms is nowhere near a real
+        // firmware boot time (LoRa radio init alone can take longer) —
+        // confirmed live 2026-07-23: with every one of Reticulum/Meshcore/
+        // Meshtastic's open() doing this same reset, a single auto-detect
+        // cycle trying multiple protocols in sequence kept re-resetting the
+        // board before it ever finished booting from the PREVIOUS attempt's
+        // reset, on both a Heltec V3 and V4, regardless of firmware family —
+        // a self-sustaining "never finishes booting" loop with a boot-time
+        // root cause hiding behind what looked like a per-protocol failure.
         let _ = port.set_dtr(false);
         let _ = port.set_rts(false);
-        tokio::time::sleep(Duration::from_millis(300)).await;
+        tokio::time::sleep(Duration::from_millis(2000)).await;
         info!(path = %path, baud = BAUD_RATE, "Opened Meshtastic serial port");
 
         Ok(Self {

core/archipelago/src/mesh/serial.rs

@@ -58,11 +58,20 @@ impl MeshcoreDevice {
             path
         ))?;
         // See probe_rnode() in reticulum.rs for why: ESP32-S3 native-USB
-        // boards reset on a DTR/RTS transition, so deassert both and settle
+        // boards (and CP2102/CH340-bridged boards wired for Arduino-style
-        // before the handshake below.
+        // auto-reset) reset on a DTR/RTS transition, so deassert both and
+        // settle before the handshake below. 300ms is nowhere near a real
+        // firmware boot time (LoRa radio init alone can take longer) —
+        // confirmed live 2026-07-23: with every one of Reticulum/Meshcore/
+        // Meshtastic's open() doing this same reset, a single auto-detect
+        // cycle trying multiple protocols in sequence kept re-resetting the
+        // board before it ever finished booting from the PREVIOUS attempt's
+        // reset, on both a Heltec V3 and V4, regardless of firmware family —
+        // a self-sustaining "never finishes booting" loop with a boot-time
+        // root cause hiding behind what looked like a per-protocol failure.
         let _ = port.set_dtr(false);
         let _ = port.set_rts(false);
-        tokio::time::sleep(Duration::from_millis(300)).await;
+        tokio::time::sleep(Duration::from_millis(2000)).await;
 
         info!(path = %path, baud = BAUD_RATE, "Opened serial port");