[B0N3-GD]

Brings meshcomod onto MeshCore v1.18.0 (upstream companion-v1.18.0, 81dbae59) as a real merge, so the next upstream merge-base is exact again.

Approach

meshcomod keeps its own transport (USB + TCP + WebSocket + BLE through MultiTransportCompanionInterface, NimBLE, BLE/Wi-Fi coexistence), its binary NodePrefs, its own AES and its CI. From upstream it takes the core and radio fixes and the new boards, and it adds 1.18's companion CLI on top, so the official app v1.50 works against meshcomod: its Command Line and its Wi-Fi Settings both run over CMD_RUN_CLI_COMMAND.

Taken from upstream

• MACThenDecrypt rejects ciphertext that is not block-aligned (#1809), plus Utils::isZeroes
• The SX126x AGC reset keeps the boosted-gain mode (#3158)
• CMD_SEND_RAW_DATA decodes multi-byte path hashes (#3235); our zero-path ota url interception still runs first
• Channel data length bound check (#3386). Incoming channel datagrams reach the app again: upstream 1.17 already delivered them, but meshcomod 1.17.x dropped them. They now go through our per-client history ring, because our CMD_SYNC_NEXT_MESSAGE never reads upstream's offline queue
• TXT_TYPE_CLI_COMMAND, the remote-CLI contact permission, and sendCommandData(txt_type)
• The board.loop() variant hook; rtc_clock.tick() is called exactly once
• Contact responses nothing else handles are forwarded as PUSH_CODE_BINARY_RESPONSE, clamped to the frame size
• The charging bolt and plug next to the OLED battery badge
• New boards and variants (ThinkNode M4/M8, Muzi Base, LR1121, ...)

Companion CLI, on our prefs

CMD_RUN_CLI_COMMAND (66) / RESP_CODE_CLI_REPLY (29). Commands use upstream's syntax and reply formats:

• get/set name, set pin, ver, board, reboot, poweroff (pending contact writes are flushed first, as CMD_REBOOT does)
• get/set radio, get freq, af, dutycycle, tx, rxdelay, radio.rxgain, path.hash.mode, multi.acks
• Wi-Fi: set wifi.ssid, set wifi.pwd (reconnects live), get/set wifi.enabled, get wifi.status, get wifi.ip, get wifi.ssid, set wifi.clear, wifi.apply. These go through the NVS Wi-Fi store the on-device UI already uses, so the app and the device stay in agreement
• Settings that have no field in our prefs (cad, int.thresh, agc.reset.interval, txdelay, direct.txdelay, tz.offset) answer Error: unsupported rather than an OK that would not survive a reboot
• get wifi.pwd works locally (app, serial) but is refused to remote-CLI callers, so a contact granted remote CLI cannot read the network password
• The USB serial CLI falls through to the same handler for anything it does not handle itself, and it gains upstream's buffer clamp

FIRMWARE_VER_CODE stays 27 (the app enables the CLI from 14).

Kept ours, on purpose

• main.cpp and the whole transport layer. Upstream's MultiSerialInterface has no USB, no WebSocket and no mDNS. Ethernet was already restored in fix: ThinkNode M7 support + three 1.17.0 merge regressions #47
• Binary NodePrefs. Upstream moved to JSON prefs; adding fields to ours shifts the layout. Upstream's JSON prefs unit test is dropped with it
• The _ui UI wiring. Upstream's MyMesh::Listener is present but not registered. All 24 _ui-> call sites are verified intact
• The ui-new, ui-orig and ui-tiny UIs. Upstream's discovery screen needs the Listener wiring, so it is not carried
• BLE PIN selection. Upstream moved it into a main.cpp we do not use, so the auto-merge had silently dropped it, which would have left every default device on PIN 0
• CAD and the interference threshold stay off, the T-Deck BME680 guard stays, and the FEM LNA keeps defaulting to off on the companion. set radio.fem.rxgain works at runtime but is not persisted

Auto-merge damage found and repaired

• The channel-name preamble and an #endif in the display paths were lost
• The new-contact alert was dropped
• Upstream FEM/AGC/CAD prefs fields that our prefs lack had been pulled in
• A NULL _prefs dereference in seven boards' CLI hooks. The companion never attaches dynamic prefs, so set radio.fem.rxgain would have crashed
• SerialWifiInterface moved from helpers/esp32/ to helpers/wifi/, and the single-transport Wi-Fi include had not followed

Verification

• All 6 shipped companion envs build (V4, V3, Wireless Paper, Xiao S3 WIO, M7 BLE, M7 Ethernet), plus V4 TFT touch and upstream's heltec_v4_companion_radio_wifi
• pio test -e native -e native_kiss_modem: 54/54 pass
• Audit: every line meshcomod added on top of upstream 1.17 was checked for presence after the merge. The only ones missing are intentional edits (version bump, the txt_type parameter, ctor init, the battery icon shift)
• Not yet done: the erased-device boot test on hardware. This must happen before any release

Not in this PR (pre-existing on main)

The repeater and room-server envs do not build: DisplayDriver's colour enum has been commented out since the 1.17 one-palette change, but those UIs still use DisplayDriver::LIGHT and friends. This merge does not touch those files. meshcomod only releases companion firmware.

🤖 Generated with Claude Code

[B0N3-GD]

Hardware test: Heltec V4 (regular OLED, V4.2 FEM), MAC 8c:fd:49:b6:6a:4c

All of this was driven over USB with the companion protocol (CMD_DEVICE_QUERY, CMD_RUN_CLI_COMMAND, CMD_GET_CONTACTS, and CMD_GET_STATS for uptime).

Upgrade path (v1.17.0.1+5dec5b2 with 27 contacts → this build, flashed component-wise, partition table unchanged)

• Boots as v1.18.0.1. Node name and all 27 contacts kept.
• 124 s soak: uptime monotonic, no reboot.
• Every read command answers in upstream's format: ver, board, get name/radio/tx/af/radio.rxgain, and get wifi.enabled/status/ssid/ip. get radio.fem.rxgain, get cad and get tz.offset answer Error: unsupported (this board is a V4.2 with no switchable LNA). Anything else answers Unknown command.
• Write path: set multi.acks, set name, set dutycycle 50, set radio ..., and set wifi.ssid / set wifi.pwd all reply OK. get wifi.pwd works locally. Out-of-range set tx 99, set path.hash.mode 5 and set af 12 are rejected with upstream's messages. The XY| prefix is reflected.
• A CLI reboot followed by re-reading the values: name, multi.acks, the duty-cycle change and the Wi-Fi credentials all persisted.
• 60 s soak with Wi-Fi retrying a network that does not exist: no reboot. set wifi.clear cleared it again.

Fresh device (erase_flash, then flash)

• First boot completes once (one ROM banner in 60 s), the AES self-test passes, no panic. It came up with a new identity.
• 131 s soak: no reboot. All CLI commands answer.
• One observation: on the first run after the erase, a single reply arrived more than 3 s late, about 20 s after boot. Two later runs answered every command in about 100 ms, so this looks like a one-off main-loop stall on the freshly formatted SPIFFS rather than the CLI. It is not reproduced.

Not covered here: remote CLI from a second node (including the get wifi.pwd refusal), app v1.50 itself, and the Wi-Fi Settings screen against a real network.