[agessaman]

Draft. Adds a companion radio firmware that also runs the MQTT observer, for #77. A node can be flashed between the repeater observer and the companion observer and keep its MQTT configuration and identity.

What changes

New role

• Five WiFi environments: heltec_v4_companion_observer_wifi, heltec_v4_expansionkit_companion_observer_wifi (adds the expansion kit's sensor I2C bus), Heltec_v3_companion_observer_wifi, Xiao_S3_WIO_companion_observer_wifi, Waveshare_S3_LR1121_companion_observer_wifi. They are not named *_observer_mqtt, so the release workflows do not build them.
• build-companion-observer-alpha.yml builds only these envs when a compobs-alpha-* tag is pushed and publishes them as a GitHub prerelease, with no flasher manifests or OTA channel.
• The companion reads the same /mqtt.json and /identity/_main as the repeater observer. With no WiFi SSID in /mqtt.json it adopts the companion's own WiFi credentials once.
• The observer CLI (get/set mqtt.*, wifi.*, memory, diagnostics) is reachable from USB serial, the app's CLI command and remote admin.
• The status message gains an additive role field (repeater, room_server, companion) so brokers can tell the roles apart. client_version is unchanged.

Decoupling from the repeater

• Observer config and CLI moved out of CommonCLI into ObserverConfig / ObserverCLI.cpp (renamed from CommonCLI_Observer.cpp), behind an ObserverCallbacks seam. MQTTBridge reads node name, radio parameters, forwarding state and role through MQTTBridgeHost instead of the repeater's NodePrefs. The repeater and companion each have a NodePrefs with virtuals, so linking both was an ODR clash.
• memory and stats-radio-diag moved into a shared NodeDiagCLI.
• CompanionObserver drives the bridge through ObserverBridgeControl, the same start / restart / late-stop-ack sequencer the repeater and room server use, with a self-heal platform that is compiled out.

Companion specifics

• Self-heal is refused: set mqtt.selfheal returns an error and no reboot driver runs, because a phone may be attached. The saved value is left alone for a later repeater flash.
• ota check, ota update and the upload portal are not supported in this version.
• On PSRAM boards the mesh object is built in PSRAM from setup(). On the Heltec V4 with five brokers that took free internal heap from about 37 KB to about 160 KB.
• Non-PSRAM boards keep the two-slot cap.
• The Heltec V4 env advertises mDNS (_meshcore._tcp). The network link brings WiFi up after setup(), so observer builds start the responder on the first link-up and retry a failed start on the next one. Plain companion builds are unchanged.
• The V4 and Xiao envs embed the full root bundle (adafruit-full), matching the repeater observer envs on those boards.
• The panic core dump is read back at boot and published once, as on the repeater.

Shared fixes found on the way

• The JWT username is rebuilt when the device identity changes.
• Observer CLI replies are bounded, and slot counts read safely before the bridge exists.

Behavior to be aware of

• Both roles write /prefs.json with their own schema, and the upstream serializer drops keys it does not know. A companion settings save therefore resets repeater-only fields, including the repeater admin password, after a flash back. This matches upstream and is documented in MQTT_IMPLEMENTATION.md; it is not changed here.
• A slot-wide set (for example mqtt.iata) restarts the bridge synchronously, about 5 to 6 s per slot, and the app link and mesh loop stall for that time. The repeater behaves the same way.
• Repeater and room-server builds change only through the refactor and the new role field.

Testing

• 783 native tests pass (after merging observer-firmware-dev at 34e658e20). New: ObserverBridgeControl with the self-heal driver unsupported, on a moving clock (it fails if the platform is flipped to supported), and role beside the widest crash and self-heal status fields.
• Builds: the five companion observer envs, heltec_v4_companion_radio_wifi, Heltec_v3_repeater_observer_mqtt, heltec_v4_repeater_observer_mqtt, Heltec_v3_room_server_observer_mqtt.
• Heltec V4 (PSRAM, five slots) on this branch: five slots connected about 20 s after reset; a full bridge restart stopped cleanly and all five were back 17 s later; a single-slot restart reconnected in 4 s; after a five-minute hold all slots were connected with 152 KB internal heap free, 139 KB largest block. Self-heal and OTA commands were refused. mDNS resolved meshcore_<name>._meshcore._tcp.local.:5000 after boot and again after a bridge restart. App TCP port 5000 accepted a connection.
• Heltec V3 (no PSRAM, two slots, stock TLS): both slots connected 11 s after reset; bridge restart and slot restart both clean; after a five-minute hold both slots connected, 52 KB free, 37 KB largest block.
• Round trip: both boards were flashed app-only from repeater observer to companion observer and back. They came back as repeaters with every slot connected and the saved mqtt.selfheal value unchanged.
• Two source reviews of the merge with observer-firmware-dev and of the ObserverBridgeControl adoption; the findings (mDNS start latch, a test that could not fail) are fixed in the last two commits.

Not tested

• Xiao S3 WIO on hardware (build only).
• The app over BLE or TCP beyond opening the port, and contact or channel persistence, on this tip. Earlier tips of the branch ran an app session on the V4 and a soak on the V3.
• mDNS across a WiFi outage.
• The late-stop-ack resume path on hardware (host tests only).
• Heltec V4 expansion kit on hardware (build only).
• Waveshare S3 LR1121 on this tip (build only). The test board's 128 KB SPIFFS is full of /bl/* files and logs fopen(/spiffs/contacts3) failed, so contact persistence was never validated there.

Addresses #77.