Feat/abstract radio connection

[zindello]

feat: Decouple radio hardware from service startup; add RadioManager

⚠️ Dependency

Requires pyMC-dev/pyMC_core#70 to be merged and released before this can be merged. That PR fixes KissModemWrapper silent thread death and sys.exit() on GPIO failure — both of which this branch depends on for correct KISS disconnect detection and GPIO error recovery. It also fixes a missing endpoint in the sx1262 radio type for updating hardware config on-the-fly.

---

The Problem

Before this change, the pyMC Repeater had a fundamental usability issue: if radio hardware
was unavailable, misconfigured, or failed, the entire service failed to start. The HTTP
server and web UI came up only if the radio initialised successfully. This meant:

• A user with a newly flashed device and no radio connected got a completely unreachable
  service — no web UI, no status, no way to diagnose the problem without SSH access.
• Any radio failure mid-run (power blip, USB disconnect) took down the entire service,
  including the web UI. The user had no visibility and no way to recover without a restart.

The net result: users who hit any hardware problem were forced to SSH into the device and
configure via the CLI. For a device intended to be deployed and managed through its web
interface, this was less than ideal.

What Changed

RadioManager — radio hardware now has its own lifecycle

A new RadioManager class owns the entire radio hardware lifecycle: connect, retry on
failure with exponential backoff (5s → 10s → 30s → 60s), report status, and reconnect
if the radio is lost mid-run. It runs as an asyncio background task and calls back into
the daemon when hardware comes up or goes away.

The HTTP server now starts unconditionally before any radio connection is attempted.
The web UI is always reachable. Radio hardware connects asynchronously in the background.

Automatic retry with backoff

If radio hardware is unavailable or fails to initialise, RadioManager retries
automatically. The user sees the current status through the web UI and /api/stats
rather than a blank page or a timeout.

Mid-run disconnect and reconnect

If the radio is lost while running (e.g. USB hardware failure, power blip on a KISS
modem), RadioManager detects the failure, tears down the dispatcher and all helpers
cleanly, and re-enters the retry loop. The HTTP server, GPS, and sensors keep running
throughout. When hardware comes back, everything reinitialises automatically.

Companion app connections survive a mid-run radio disconnect — the companion disconnects
when the radio goes away, and can reconnect and resume once the radio comes back.

Clearer error messaging

The "Repeater handler not initialized" error that appeared in the packet log when the
radio wasn't connected has been replaced with "Radio not available — connecting or
hardware unavailable", which tells the user what is actually happening.

Bugs Fixed

KISS radio disconnect not detected

When a KISS modem loses its serial connection, KissModemWrapper._rx_worker and
_tx_worker die silently without setting is_connected = False. A paired fix in
pymc_core now sets is_connected = False on I/O failure. RadioManager._wait_for_disconnect()
polls radio.is_connected every second for radios that expose it, and falls back to
asyncio event-wait for those that don't (SX1262).

CH341 singleton not reset on reconnect

The CH341Async singleton was not being reset on radio cleanup, causing
sx1262_ch341 radios to fail on reconnect. Fixed in RadioManager._cleanup_radio(). This has not been tested yet as I do not have CH341 hardware to test

local_hash_bytes not initialised in __init__

local_hash and local_identity were initialised to None in __init__ but
local_hash_bytes was not, risking AttributeError before initialize() completes.

Radio hardware leaked on post-init CancelledError

self._current_radio was assigned after the post-init config block. If CancelledError
fired during post-init (e.g. shutdown during startup), _cleanup_radio() found
_current_radio = None and skipped hardware teardown, leaking the radio handle.

Dispatcher None during reconnect cycles

config_manager.live_update_daemon() was accessing dispatcher without a None guard.
After RadioManager was introduced, dispatcher is legitimately None during reconnect
cycles. Added guard to prevent AttributeError.

New API Surface

Adds a radio key to the /api/stats response. Additive only — no existing fields
changed.

This field is not yet consumed by the web UI but is available for future use — dashboard
status indicators, external monitoring, companion app integration.

"radio": {
  "status": "connected",
  "type": "sx1262",
  "error": null,
  "connected_at": 1747291483.925,
  "last_error_at": null,
  "retry_count": 0,
  "retry_delay_seconds": 0
}