Context

PR #2772 (merged at 00:40 UTC) migrated `RadioSetupDialog` to inherit from `PersistentDialog` and converted the primary `Settings → Radio Setup` menu entry to use `showOrRaisePersistent(m_radioSetupDialog, ...)`. However, MainWindow.cpp contains three additional inline `new RadioSetupDialog(...)` construction sites that the migration didn't touch:

Each of these constructs a fresh `RadioSetupDialog` and shows it directly, bypassing `showOrRaisePersistent`.

Symptoms (post-#2772 regression)

1. Multiple instances: clicking `Settings → Radio Setup` then `Settings → FlexControl` opens two independent RadioSetupDialog windows. The user expects "raise existing instance, switch to the FlexControl tab" — they get two windows fighting for focus.
2. Frameless toggle propagation broken: dialogs constructed via these three sites are NOT added to MainWindow's `m_persistentDialogs` registry. When the user toggles `View → Use Frameless Windows`, the primary-entry dialog updates, but the three shortcut-entry dialogs continue to render with the previous mode until manually closed and reopened.
3. Geometry inconsistency: each of these creates a fresh dialog which auto-loads the `RadioSetupDialogGeometry` key on construction — so the size/position is roughly right, but the four code paths' "open shortcut to tab X" semantics aren't consistent.

Pre-#2772 behavior

Before #2772, none of the four sites went through any "raise existing" path — the original Settings → Radio Setup site DID have a `if (m_radioSetupDialog) { raise(); activateWindow(); return; }` guard, but the three shortcut sites didn't. So this is a partial regression of a pre-existing inconsistency, but it's more visible now because `PersistentDialog` puts an instance into the global registry and the three shortcut sites are silently skipping the registry.

What to do

Convert each of the three inline constructions to use `showOrRaisePersistent` and then perform the tab-switch (or initial-tab-select) on the returned dialog. Pseudocode for the FlexControl entry point:

connect(flexControlAction, &QAction::triggered, this, [this] {
    const bool wasFresh = !m_radioSetupDialog;
    showOrRaisePersistent(m_radioSetupDialog, &m_radioModel, m_audio,
                          &m_tgxlConn, &m_pgxlConn, &m_antennaGenius);
    if (wasFresh && m_radioSetupDialog) {
        // wire the txBandSettingsRequested + sliceLetterDisplayModeChanged
        // signals exactly like the primary Settings → Radio Setup entry
    }
    if (m_radioSetupDialog)
        m_radioSetupDialog->selectTab(QStringLiteral("Serial"));  // or whatever tab
});

Apply the same shape to USB Cables (selectTab "USB Cables") and the XVTR overlay (selectTab "XVTR"). The dialog already has `selectTab(const QString&)` from PR #2772 — check that all three of FlexControl / USB Cables / XVTR tab names are reachable via it.

Acceptance criteria

• Clicking any of the four Radio Setup entry points opens (or raises) one dialog instance.
• FlexControl / USB Cables / XVTR entries auto-switch to the corresponding tab on every click.
• `View → Use Frameless Windows` toggle propagates correctly to the dialog regardless of which entry point opened it.
• Closing the dialog deletes the instance (existing `WA_DeleteOnClose` behavior from `showOrRaisePersistent`).
• No new tests required — this is a UI-flow consistency fix.

Pickup

AetherClaude-eligible. Mechanical conversion, three near-identical sites following the recipe already proven in PR #2742, #2772, #2774. Lines are well-localized; no protocol or threading changes.

73, Jeremy KK7GWY & Claude (AI dev partner)