feat: secure remote command execution over MQTT (slot-based)

[agessaman]

Summary

Re-implements the JWT-authenticated remote serial command execution over MQTT
feature (originally a single commit on the long-stale mqtt-bridge-implementation-remote,
~1223 commits / 6 months behind) onto the current slot-based observer MQTT
architecture. This is a re-implementation, not a cherry-pick: the old feature was built
around a fixed two-analyzer (US/EU) client model and NodePrefs-resident MQTT config,
both of which no longer exist.

An admin holding an authorized Ed25519 key can publish a signed command to
meshcore/{IATA}/{DEVICE}/serial/commands; the device verifies it, runs it through the
existing CLI, and publishes a signed reply to .../serial/responses.

Design decisions (from the reviewed plan)

• Testable policy engine. All security-critical logic (replay/nonce, per-key rate
  limit, command blacklist, target filtering, authorization ordering) lives in a new pure
  RemoteControl helper with the JSON/base64/Ed25519/clock behind injected seams, so it is
  fully host-tested without MQTT or crypto. The bridge implements the seams (JWTHelper +
  LocalIdentity, MQTTPrefs + ACL callback, CLI callback, millis/time).
• Per-slot enable + global kill switch. set mqtt.remote on|off is the master
  (default off); set mqttN.remote on|off gates each slot (default on). Effective =
  master AND slot. Subscriptions are reconciled live by the bridge task, so the kill switch
  unsubscribes every slot and drops any in-flight command without a WSS restart.
• Dropped from the old feature: the memory-pressure degraded-mode (built on the removed
  two-analyzer model; slots already bound memory via PSRAM active-slot caps + circuit
  breakers), and the -native-observer-{hash} version-string change (collides with the
  observer release-channel versioning).
• letsmesh contract unchanged: topic namespace and JWT/Ed25519 request/response format
  are preserved.

Security posture

• Remote commands run with a non-zero sentinel sender_timestamp, so the serial-only
  CLI gates (get prv.key, set freq, erase, …) treat them as not local console and
  refuse — a remote admin gets mesh-admin-equivalent access, never console-only access.
  (The old feature passed 0, i.e. full serial access.)
• Authorization via the ACL admin list (mqtt.useacl on, default) or an explicit
  mqtt.admin key; command blacklist (get wifi.pwd, set mqtt.admin); reboot refused;
  nonce replay + per-key rate limiting run before the expensive signature verify.
• get mqtt.admin reveals the key over serial only.

Preferences / fleet migration

New fields are appended to the MQTTPrefs tail (mqtt_remote_enabled, mqtt_use_acl,
mqtt_slot_remote_enabled[], mqtt_admin_public_key); payload version stays 1. A new
kV1PreRemotePayloadSize (2864) decode checkpoint means a /mqtt_prefs written by current
field firmware still loads as Current, with the remote fields defaulting (master off, ACL
on, per-slot on). A forward (2940-byte) file is held, not discarded by older firmware.
static_asserts lock the offsets.

CLI

set/get mqtt.remote, mqtt.useacl, mqtt.admin, and per-slot set/get mqttN.remote.

Testing

• pio test -e native: 238/238 pass, including a new 23-case test_remote_control
  suite (replay, rate-limit, blacklist, target filtering, ACL-vs-key authz, malformed JWT,
  timeout, response construction) and 2 new codec migration tests (pre-remote load + full
  round-trip).
• ESP32 builds green: Heltec_v3_repeater_observer_mqtt and
  Heltec_v3_room_server_observer_mqtt.

Not included (possible follow-ups)

• Webconfig UI exposure of the new remote fields (CLI-only for now).
• On-target hardware test (end-to-end command round-trip against a broker).
• Confirmation that the letsmesh.net server side still targets this topic/JWT contract now
  that brokers are preset-based.

Commits

jwt verify → RemoteControl engine + tests → MQTTPrefs fields + codec → CLI → bridge
glue → example wiring.