[Elektr0Vodka]

What changed

Ports the SNMPv2c agent from the Dutch-MeshCore observer firmware (dmc-observer-dev) to the Wi-Fi companion. Read-only GET/GETNEXT/GETBULK on UDP 161.

• examples/companion_radio/CompanionSNMP.{h,cpp} (new): the agent, its OID table and the snmp CLI commands. The whole file compiles to nothing without WITH_SNMP.
• src/helpers/esp32/WifiRuntimeStore.{h,cpp}: snmp_en (default off) and snmp_comm (default public) in the existing NVS namespace.
• examples/companion_radio/main.cpp: one call per loop, only when Wi-Fi was brought up this session (same rule as the TCP server).
• examples/companion_radio/MyMesh.cpp: one hook in handleCommand.
• src/helpers/esp32/MultiTransportCompanionInterface.h: getTcpConnectedCount() accessor.
• variants/heltec_v3, variants/heltec_v4, variants/heltec_wireless_paper, variants/xiao_s3_wio: -D WITH_SNMP=1 and 0neblock/SNMP_Agent @ 2.1.0 on Heltec_v3_companion_radio_usb_tcp (and its _boot_debug child), heltec_v4_companion_radio_usb_tcp, Heltec_Wireless_Paper_companion_radio_usb_tcp and Xiao_S3_WIO_companion_radio_usb_tcp.
• docs/companion_snmp.md (new): commands, OID reference, sizes, how to add it to another env.

Why

So monitoring tools (LibreNMS, Zabbix, RTFM-EV's SNMP poller) can poll a companion the same way they poll an observer.

Notes for review

• Off by default at runtime. set snmp on allocates the agent and binds UDP 161; until then nothing is allocated. Settings apply live, no reboot. They live in NVS, so the binary NodePrefs layout is untouched.
• OID compatibility. Same enterprise subtree (1.3.6.1.4.1.99999) and the same .1 system, .2 radio, .4 memory and .5 network layout as the observer, so one poller reads both. The observer's .3 MQTT group is left out. Companion-only values go in .6: TCP clients, WebSocket clients, contacts, channels, RX air time.
• Battery is .1.4.0 (mV). It was added to the observer agent at the same time: feat(snmp): battery, MCU temperature, reset reason, mesh, filter and duty gate OIDs Dutch-MeshCore/MeshCore#16.
• Values are read when a request arrives. The agent runs in the main loop, the same context as the mesh, so no locking is needed and nothing is stale.
• The agent stops when the Wi-Fi link drops and restarts its socket when the link comes back, including after the escalation path that tears the radio down to WIFI_OFF.
• get snmp.community is refused over remote CLI, like get wifi.pwd.
• Touch is deliberately left out for now. It is tight on internal RAM (BLE co-init is already heap-gated there) and needs a heap reading on hardware first.
• The Heltec Wireless Tracker has no meshcomod Wi-Fi companion env yet (only USB and BLE), so it needs that env before SNMP can be added.

How it was tested

pio run with DISABLE_DEBUG=1, baseline (main) vs this branch:

Env	Flash	Static RAM	App slot used
Heltec_v3_companion_radio_usb_tcp	1,591,601 to 1,625,157 B (+33,556)	110,136 to 110,472 B (+336)	48.6% of 3.19 MB
heltec_v4_companion_radio_usb_tcp	1,589,953 to 1,623,293 B (+33,340)	110,100 to 110,444 B (+344)	24.8% of 6.25 MB
Heltec_Wireless_Paper_companion_radio_usb_tcp	1,537,781 to 1,570,937 B (+33,156)	150,480 to 150,824 B (+344)	47.0% of 3.19 MB
Xiao_S3_WIO_companion_radio_usb_tcp	1,534,637 to 1,567,657 B (+33,020)	151,328 to 151,672 B (+344)	46.9% of 3.19 MB

All four build with no new warnings. Paper and Xiao start from about 40 KB more static RAM than the V3, so they are the ones to watch for free heap on hardware. Not yet tested on hardware: no snmpwalk against a running companion, and runtime heap with Wi-Fi, BLE and the agent all up is not measured yet (the [snmp] agent up serial line prints free heap when it starts).

Firmware and build impact

Only the four envs above change. Adds one library dependency to them. No prefs, protocol or OTA naming change. No version bump.

No issue to close.