fix: parent background image dialog to top-level window, use Qt dialog (#2865)

## Summary

Fixes #723.

Setting a background image via Display → Background → "Choose…" caused
AetherSDR to become unresponsive on Linux, requiring a force-kill. The
application appeared frozen with no dialog visible.

## Root cause

Two compounding problems in the single \`QFileDialog::getOpenFileName\`
call at \`MainWindow.cpp:10800\`:

**1. Wrong parent widget.** The dialog was parented to \`sw\` — the
\`SpectrumWidget\`, which is a \`QRhiWidget\` backed by a native
hardware render surface. On X11/Wayland the window manager cannot
reliably establish a transient-for relationship between a native modal
dialog and a QRhi surface. The modal grab fires but the dialog cannot
receive focus or complete initialization, wedging the GUI thread.

**2. Native dialog backend.** Without \`DontUseNativeDialog\`, Qt routes
through the platform portal (xdg-desktop-portal, GTK, or KDE depending
on desktop environment). On Linux Mint Cinnamon and other environments
where the portal is absent or misconfigured, the blocking
\`getOpenFileName\` call never returns.

Either problem alone is sufficient to reproduce the hang; together they
make it near-certain on affected Linux desktops.

## Fix

Two argument changes to the one affected call site:

- \`sw\` → \`sw->window()\`: parents the dialog to the top-level
\`QMainWindow\`, which has a valid native window handle the WM can use
for transient-for.
- Add \`QFileDialog::DontUseNativeDialog\`: forces Qt's own
cross-platform file dialog, bypassing the portal/GTK/KDE backend
entirely.

Applied unconditionally — no platform guards needed. The Qt dialog
renders correctly on all three platforms; the visual difference from the
system-native dialog on macOS/Windows is cosmetic only.

## Other \`getOpenFileName\` call sites — not affected

All other file dialog calls in the codebase (\`RadioSetupDialog\`,
\`DvkPanel\`, \`MemoryDialog\`, \`DxClusterDialog\`,
\`ProfileImportExportDialog\`) parent to \`this\` (a standard QDialog or
QWidget), not a QRhi surface. They are unaffected by this root cause and
require no changes.

## Out of scope

\`SpectrumWidget::setBackgroundImage\` decodes the image synchronously
on the GUI thread (\`QImage(path)\`). For very large files this could
produce a brief stall. This is a pre-existing minor concern, not the
cause of the hang reported in #723, and is tracked separately.

## Test plan

- [ ] On a Linux desktop (Cinnamon, MATE, or XFCE): Display → Background
→ "Choose…" — confirm dialog opens without freezing
- [ ] Select a valid image — confirm it appears as the spectrum
background
- [ ] Cancel the dialog — confirm the application remains responsive
- [ ] Confirm behavior unchanged on macOS and Windows (dialog opens,
image selection works)
- [ ] Confirm the "Clear" button still resets to the default background

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: NF0T

src/gui/MainWindow.cpp

@@ -10836,8 +10836,13 @@ void MainWindow::wirePanadapter(PanadapterApplet* applet)
             sw, &SpectrumWidget::setWfBlankerThreshold);
     connect(menu, &SpectrumOverlayMenu::backgroundImageRequested,
             this, [this, sw] {
-        QString path = QFileDialog::getOpenFileName(sw, "Choose Background Image",
-            QString(), "Images (*.png *.jpg *.jpeg *.bmp)");
+        QString path = QFileDialog::getOpenFileName(
+            sw->window(),
+            "Choose Background Image",
+            QString(),
+            "Images (*.png *.jpg *.jpeg *.bmp)",
+            nullptr,
+            QFileDialog::DontUseNativeDialog);
         if (path.isEmpty()) return;
         sw->setBackgroundImage(path);
         auto& s = AppSettings::instance();