Add feature to configure TCI and rigctld bind interfaces

Summary

The TCI and rigctl/CAT external surfaces can key the transmitter with no authorization gate and no per-client identity. Any client that can reach the port can transmit. The automation surface — the one the ApX RFC cites as precedent — is gated; these two are not.

This is a property of main independent of #5270; filed separately at the RFC author's request so it does not ride on that thread. Companion to #5087: that issue is "no identity to log", this one is "no identity to authorize".

Measured against origin/main (56edc21b)

Both surfaces reach a keying path directly.

Neither has any gate. Grepping both files for ALLOW_TX, allowTx, isTxAllowed, txGate:

src/core/TciServer.cpp      : 0 gate references
src/core/RigctlProtocol.cpp : 0 gate references

Both listen on all interfaces, unauthenticated.

• TciServer.cpp:462 — m_server->listen(QHostAddress::Any, port) on a QWebSocketServer in NonSecureMode, with no authentication step in the WebSocket upgrade.
• CatPort.cpp:70 — m_tcpServer->listen(QHostAddress::Any, port); CatPort is the rigctl transport (it includes RigctlProtocol.h and owns m_rigctlClients).

The automation surface, by contrast, is gated — AutomationServer.cpp:

• :2235 QLocalServer (named local socket, not a TCP port)
• :2240 setSocketOptions(QLocalServer::UserAccessOption)
• :2311 m_txAllowed = qEnvironmentVariableIsSet("AETHER_AUTOMATION_ALLOW_TX")

So the same capability is inert-until-armed on one surface and open on the other two.

There is no per-client identity to gate on even if one wanted to. ClientState (TciServer.cpp:708) holds socket, protocol and resamplers — no principal, no grants. PttSource (TransmitModel.h:167) is a provenance annotation for downstream consumers, not an arbitration identity: every external client collapses to Dax, which is why #5087 exists.

Why this matters

A station running AetherSDR with TCI enabled on a routable interface is one reachable port away from a third party keying the transmitter. That is an unattended-transmitter and licensing exposure, not only a software defect — the licensee is responsible for what the station radiates.

Worth being precise about severity: this is not a remote code execution, and on a typical home LAN behind NAT the practical exposure is limited. But "limited by the network topology the operator happens to have" is not the same as "gated", and TCI is commonly enabled for legitimate third-party clients, so the port is often deliberately open.

What I am not proposing

I am deliberately not proposing the fix here. The approved Stage 3/4 plan already commits to converging GUI/automation/TCI/CAT/rigctl/DAX onto one engine-owned arbiter, and #5270's trust-model section now depends on that convergence. A per-surface patch bolted on now would likely be thrown away by it, and could give a false sense that the general problem is solved.

What seems worth deciding is the interim position, since the arbiter is not imminent:

1. Do TCI and rigctl get an AETHER_AUTOMATION_ALLOW_TX-style inert-until-armed gate now, accepting that it is a stopgap with the same known weaknesses (process-global, no per-client granularity)?
2. Or does the listen address default to loopback, so reaching the surface at all requires a deliberate act?
3. Or is the current behaviour accepted as intended for these surfaces, and documented as such, so operators know to firewall the ports?

Option 3 is a legitimate answer for a ham-radio application where the operator is assumed to control their own network. I would just rather it were a stated position than an unexamined default — the same request I made of the applet radio binding in #5270.

Environment

• origin/main at 56edc21b
• All line references verified against that SHA on 2026-08-27; no local build or runtime testing was involved, and no transmitter was keyed in the course of filing this.