[regression] Suppress routine connect notices during startup

[jensenpat]

Summary

• Suppress routine radio info messages like Client connected from IP ... while the startup connection-notice grace window is active.
• Reuse the existing client-connection suppression window for both M-message notices and client status replay notices.
• Re-arm that grace window around handle assignment, GUI registration, and client-list subscription replay so normal connect handshakes stay quiet while later client joins still surface.

Why

During initial radio connection, the radio can emit routine informational connection messages before the normal connected-client status replay finishes. Those self-connect notices should remain quiet during startup, while warning, error, and fatal radio messages should continue to surface normally.

Validation

• cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=RelWithDebInfo
• cmake --build build --parallel 22
• ctest --test-dir build --output-on-failure --parallel 22 — 15/15 passed
• Launched build/AetherSDR.app

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

[aethersdr-agent]

Thanks @jensenpat — this looks like a clean, well-scoped regression fix. A few observations:

Looks good

• Refactor of the inline timer check into armClientConnectionNoticeSuppression() / clientConnectionNoticeSuppressionActive() is a nice readability win and keeps the four arming points consistent.
• The new isRoutineClientConnectionInfo() helper drops naturally into the existing anonymous namespace and uses a static const QRegularExpression like the surrounding patterns.
• Suppression is correctly gated on MessageSeverity::Info only, so Warning/Error/Fatal radio messages still surface — important for the operator-facing surface.
• The early-return for MessageType::Handle in onMessageReceived() is safe: that handler previously only dispatched on Message/Status and fell through silently for everything else. Arming the gate there closes the ordering hole described in the comment.
• Re-arming around client gui response and just before sub client all is the right pair of hook points to keep the startup status replay quiet without affecting later joins.

One minor thing

• bool isRoutineClientConnectionInfo(const QString& text) matches both connected and disconnected. The PR description only mentions connect notices, but the broader regex looks intentional (disconnect replays during the same startup window would be equally noisy). Worth confirming that's deliberate — if so, no change needed.

Nothing blocking. Nice surgical fix.