fix(host/uart): deliver RX to host and survive sustained bidirectional load

Two regressions on UART boards (heltec_v3_uart, etc.):

1. RADIO_THROTTLED was never cleared on UART. The throttle gate at
   src/radio.rs:2017 (added in 276f941, "chart-first restructure ...
   soak hardening") silently drops async RX while the flag is true.
   USB host_task clears it on first successful write_packet
   (src/host/usb.rs:354/373), but the UART path was never updated --
   every RX event was dropped from boot. The OLED bar lit up
   regardless because record_packet announces PacketRx before the
   gate. Mirror the USB pattern: clear on successful tx.write_all,
   re-arm on failure.

2. Once RX flowed, sustained bidirectional spam tripped the §3.4
   inactivity watchdog spuriously. The select3-based loop serialised
   read and write; tx.write_all (~25 ms per max frame at 115_200
   baud) blocked the read poll long enough for last_frame_at to age
   past 1000 ms under a saturated outbound queue. The Reset cascaded
   to radio (Unconfigured) and display (splash), leaving subsequent
   host TX commands timing out waiting for TX_DONE. Restructure
   host_task into two sub-loops joined in the same task: read_loop
   owns rx + watchdog, write_loop owns tx + throttle. The read future
   re-polls on every executor wake regardless of write progress.
   Same executor, disjoint borrows on the split rx/tx halves, no
   Mutex needed.

Also reset the FrameDecoder when the watchdog fires so a host that
resumes mid-frame resyncs cleanly on the next 0x00 sentinel (USB
gets this for free via DTR-drop reset; UART has no DTR).

Build: bump esp-hal/esp-rtos/esp-backtrace/esp-println version
requirements (1.0->1.1, 0.2->0.3, 0.18->0.19, 0.16->0.17) to match
what the upstream esp-rs/esp-hal main branch now publishes. cargo
update had invalidated the [patch.crates-io] entries since the
patched versions were no longer semver-compatible with the old
top-level requirements, which silently dropped the patches and fell
back to crates.io releases that pin embassy-executor 0.9 (mismatched
with our 0.10).

Cargo.toml

@@ -14,8 +14,10 @@ homepage = "https://github.com/donglora/firmware"
 keywords = ["lora", "radio", "embedded", "usb", "firmware"]
 categories = ["embedded", "hardware-support", "no-std"]
 
-# NOTE: esp-rtos patched from GitHub main (see [patch.crates-io] below).
-# Remove patches once esp-rtos publishes with embassy-executor 0.10 support.
+# NOTE: esp-{hal,rtos,backtrace,println} patched from GitHub main (see
+# [patch.crates-io] below). The patch versions must stay semver-compatible
+# with the version requirements above, or Cargo silently drops the patch
+# and falls back to the (older) crates.io release.
 [dependencies]
 cfg-if = "1.0"
 critical-section = "1.2"
@@ -31,7 +33,7 @@ embassy-usb-driver = "0.2"
 ucobs = { version = "0.3", features = ["legacy-msrv"] }
 heapless = "0.9"
 donglora-protocol = "1"
-hsmc = { version = "0.3", default-features = false, features = ["embassy", "trace-defmt"] }
+hsmc = { version = "0.4", default-features = false, features = ["embassy", "trace-defmt"] }
 # Local path while iterating on CAD IRQ-clear / standby-after-CAD fixes.
 # Switch back to git fork (then crates.io) once changes are upstreamed.
 lora-phy = { path = "../../lora-rs/lora-phy", features = ["defmt-03"] }
@@ -50,17 +52,17 @@ embassy-futures = "0.1"
 # Xtensa ESP crates — requires esp toolchain (espup). The chip feature
 # (esp32 / esp32s3) is selected per board via the board-level feature flag
 # below, so the same dep lines support both classic ESP32 and ESP32-S3.
-esp-backtrace = { version = "0.18", optional = true, features = [
+esp-backtrace = { version = "0.19", optional = true, features = [
   "panic-handler",
   "defmt",
 ] }
-esp-hal = { version = "1.0", optional = true, features = [
+esp-hal = { version = "1.1", optional = true, features = [
   "unstable",
 ] }
-esp-println = { version = "0.16", optional = true, features = [
+esp-println = { version = "0.17", optional = true, features = [
   "defmt-espflash",
 ] }
-esp-rtos = { version = "0.2", optional = true, features = [
+esp-rtos = { version = "0.3", optional = true, features = [
   "embassy",
 ] }
 
@@ -100,13 +102,22 @@ minijinja = "2.18"
 owo-colors = "4.3"
 
 [features]
-# The `embassy` feature gates the async-actions codepath inside the `hsmc`
-# statechart macro. Its `#[cfg(feature = "embassy")]` attributes are
-# evaluated in *this* crate's context (a proc-macro cfg quirk), so every
-# board feature must enable it. `tokio` is declared only to silence the
-# macro's `#[cfg(feature = "tokio")]` checks.
+# Bridge features for hsmc's macro-expanded `#[cfg(feature = "...")]`
+# attributes. Macros expand into the *call-site* crate, so any cfg the
+# macro emits is evaluated against THIS crate's feature set, not hsmc's.
+# That means enabling `hsmc/embassy` or `hsmc/trace-defmt` via the dep
+# only activates them inside hsmc's own compilation — for the cfg gates
+# inside expanded macro bodies to fire here, we need same-named features
+# in this Cargo.toml. `tokio` is declared just to silence the macro's
+# `#[cfg(feature = "tokio")]` checks.
+#
+# `trace-defmt` must be in every board feature so chart trace lines
+# (entries, exits, transitions, etc.) actually compile in. Without it,
+# hsmc 0.4's `__chart_observe!` macro expands to nothing for the defmt
+# arm and you get silent statecharts.
 embassy = []
 tokio = []
+trace-defmt = []
 # When enabled, replaces the display task with a LED-based diagnostic
 # blinker driven by `crate::debug_blink::CHECKPOINT`. Used for diagnosing
 # the firmware on UART-only boards where defmt output would corrupt the
@@ -114,13 +125,15 @@ tokio = []
 # a human watches the pattern and reports N to determine where execution
 # reached / stopped.
 debug-checkpoint = []
-# NOTE: chart auto-tracing is wired in unconditionally via the
-# `trace;` keyword in each `statechart!` and the `hsmc/trace-defmt`
-# feature on the dependency. Whether the trace lines actually emit at
-# runtime is controlled by defmt's standard compile-time level filter
-# (`DEFMT_LOG` env var). Release/shipping builds with `DEFMT_LOG`
-# unset (or `off`) compile every chart trace call out to nothing —
-# zero overhead, no separate cargo feature needed.
+# NOTE: chart auto-tracing in hsmc 0.4 emits `__chart_observe!` calls
+# whose defmt arm is gated on `#[cfg(feature = "trace-defmt")]`. That
+# cfg is evaluated against THIS crate (proc-macro cfg quirk above), so
+# every board feature includes `trace-defmt` to keep the arm live. The
+# `trace;` keyword in `statechart!` blocks is deprecated in 0.4 and
+# no longer gates emission. Whether trace lines actually emit at
+# runtime is still controlled by defmt's standard compile-time level
+# filter (`DEFMT_LOG` env var) -- release builds with `DEFMT_LOG`
+# unset compile the calls out to nothing.
 # When enabled, the SH1106 OLED driver emits a defmt::info! line for
 # every I2C transaction it issues — bytes, lengths, addresses. Used to
 # debug the embassy_nrf::twim assertion panic at twim.rs:541 (cannot
@@ -131,6 +144,7 @@ debug-checkpoint = []
 debug-twim = []
 heltec_v3 = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -142,6 +156,7 @@ heltec_v3 = [
 ]
 heltec_v3_uart = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -153,6 +168,7 @@ heltec_v3_uart = [
 ]
 heltec_v4 = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -164,6 +180,7 @@ heltec_v4 = [
 ]
 elecrow_thinknode_m2 = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -175,6 +192,7 @@ elecrow_thinknode_m2 = [
 ]
 lilygo_tbeam_supreme = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -186,6 +204,7 @@ lilygo_tbeam_supreme = [
 ]
 lilygo_tbeam = [
   "embassy",
+  "trace-defmt",
   "dep:esp-backtrace",
   "dep:esp-hal",
   "dep:esp-println",
@@ -197,6 +216,7 @@ lilygo_tbeam = [
 ]
 rak_wisblock_4631 = [
   "embassy",
+  "trace-defmt",
   "dep:cortex-m",
   "dep:cortex-m-rt",
   "cortex-m-rt/set-vtor",
@@ -208,6 +228,7 @@ rak_wisblock_4631 = [
 ]
 wio_tracker_l1 = [
   "embassy",
+  "trace-defmt",
   "dep:cortex-m",
   "dep:cortex-m-rt",
   "cortex-m-rt/set-vtor",
@@ -219,6 +240,7 @@ wio_tracker_l1 = [
 ]
 waveshare_rp2040_lora = [
   "embassy",
+  "trace-defmt",
   "dep:cortex-m",
   "dep:cortex-m-rt",
   "dep:defmt-rtt",
@@ -228,10 +250,11 @@ waveshare_rp2040_lora = [
   "embassy-executor/executor-thread",
 ]
 
-# REVISIT: esp-rtos 0.2.0 on crates.io pins embassy-executor ^0.9. The
-# esp-rs/esp-hal main branch already supports 0.10. Remove these patches once
-# esp-rtos publishes a release with embassy-executor 0.10 support. Track:
-#   https://github.com/esp-rs/esp-hal/tree/main/esp-rtos
+# REVISIT: pulling esp-{hal,rtos,backtrace,println} from esp-rs/esp-hal main
+# to ride ahead of crates.io releases (notably for embassy-executor 0.10
+# support in esp-rtos). When bumping the upstream rev, also bump the version
+# requirements above to stay semver-compatible — Cargo silently ignores a
+# patch whose version falls outside the requested range.
 [patch.crates-io]
 esp-hal       = { git = "https://github.com/esp-rs/esp-hal.git", branch = "main" }
 esp-rtos      = { git = "https://github.com/esp-rs/esp-hal.git", branch = "main" }