WIP: Fix packet loss in the ESP-NOW and RS232 bridges

[ViezeVingertjes]

ESP-NOW

• onDataRecv() called _mgr->allocNew() and queueInbound() straight from the
  Wi-Fi task. PacketQueue has no locking, so packets leaked from the 32 entry
  pool until allocNew() returned NULL and the node dropped both LoRa and
  bridged receives. Callbacks now only fill a ring buffer; the rest happens in
  loop(), like RS232Bridge already did.
• sendPacket() ran writeTo() into a 246 byte buffer and checked the size
  afterwards. writeTo() can emit 253 bytes.
• esp_now_send() returning ESP_ERR_ESPNOW_NO_MEM under burst load discarded
  the packet. Frames now queue and retry, with a timeout so a lost send callback
  cannot wedge the queue.
• Power save was left on, so the receiver dozed through broadcasts.
• Blank bridge.secret caused a modulo by zero.

RS232
No threading bug, but it discarded fully received frames when the pool was empty.
Frames now queue and convert once a slot frees up. Parser moved into
BridgeSerialFramer, fixing zero length frames reaching readFrom() and
rejected frames swallowing the next header.

New commands
get bridge.rxstats, get bridge.txstats, set bridge.stats reset, on both
bridge types. Comparing one node's TX against another's RX in shows whether
frames are lost on the link or locally.

Known limit: packets above 246 bytes still cannot cross the ESP-NOW bridge.
Counted as TX big now. Fixing it needs fragmentation.

62 new unit tests in the existing native env (77 total). Builds checked on
ESP32, nRF52, RP2040 and STM32.

Contains LLM assisted changes

[Currently being tested]