[ux] Suppress interlock error dialogs

[jensenpat]

Summary

• Suppress generic modal dialogs for interlock radio M-messages in the main radio message handler.
• Leave the existing interlock panadapter/waterfall notification path as the operator-facing surface for TX interlock blocks.
• Preserve modal dialogs for non-interlock warning/error/fatal radio messages.

Testing

• cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo
• cmake --build build --parallel 22
• Launched /Users/patj/Documents/AetherSDR/.worktrees/interlock-modal-suppression/build/AetherSDR.app
• git diff --check

👨🏼‍💻 Generated with OpenAI Codex (GPT-5.5 Pro 4/23) and tested by @jensenpat

[aethersdr-agent]

Thanks @jensenpat — the intent is reasonable, and the comment update accurately reflects the new behavior. A few things worth thinking through before merge:

1. The panadapter overlay isn't always armed when an interlock M-message arrives.

RadioModel::armInterlockNotification() sets a ~6s window (RadioModel.cpp:794-796) triggered by local PTT/tune intent, and emitInterlockNotification() is only fed from local-PTT preflight and TX-filter codepaths (RadioModel.cpp:322, 339). If the radio raises an interlock M-message outside that window — asynchronous ATU/amp interlock state changes, another GUI client transmitting, RX-antenna interlock transitions — neither the overlay nor (now) the modal will fire, and the operator only sees qCWarning/qCCritical log lines they're not watching.

Worth confirming the assumed coverage: are all interlock M-messages we see in practice strictly TX-preflight blocks that coincide with a local PTT attempt? If not, consider routing the suppressed M-message through emitInterlockNotification() directly so the overlay surfaces it regardless of armed state:

if (interlockMessage) {
    m_radioModel.emitInterlockNotification(text, QStringLiteral("radio-m:") + text);
    break;
}

(That also gets you the dedup behavior in emitInterlockNotification for free.)

2. text.contains("interlock", Qt::CaseInsensitive) is a fairly broad net.

Anything from the radio whose text happens to mention "interlock" — including potentially useful messages like "interlock override accepted", "external interlock cable disconnected", future radio strings we don't control — will be silently swallowed at Warning/Error/Fatal. If the upstream M frame has a numeric code or category available before string-formatting (and PR #2785's parsing exposes it), keying off that would be more durable than a substring.

3. Fatal severity is grouped in with Warning/Error.

The justification in the comment ("the interlock status path already surfaces actionable TX blocks") is plausible for Warning/Error, but MessageSeverity::Fatal typically indicates an unrecoverable state that the operator really should see explicitly. Worth a deliberate call on whether Fatal should pass through even for interlock — or at minimum keep a status-bar toast as a fallback when the modal is suppressed so something is operator-visible.

Otherwise the diff is small, comment-faithful, and the cases that are covered by the existing overlay path will behave correctly.