Fix server GUI not exiting on KDE (#3016)

[mcfnord]

Note

📡 STAND BY FOR AN LLM-AUTHORED MESSAGE.

Fixes #3016.

On some desktop environments — reported on KDE with Qt 5.15 (Ubuntu 22.04+, Fedora 37+) — closing the server GUI (X button, Window → Exit, Ctrl+Q, or the tray Exit entry) only hides the window. The process and the system tray icon keep running, and the only way out is killall. On Windows the same actions terminate the process as expected.

This applies the pragmatic fix that project member @dingodoppelt reported as working in the issue thread: explicitly call QApplication::quit() at the end of CServerDlg::closeEvent, after the geometry is saved and the event is accepted.

void CServerDlg::closeEvent ( QCloseEvent* Event )
{
    // store window positions
    pSettings->vecWindowPosMain = saveGeometry();

    // default implementation of this event handler routine
    Event->accept();

    // ... KDE workaround ...
    QApplication::quit();
}

Scope: one added call plus the #include <QApplication> it needs — server dialog only, exit path only. Nothing on the client, the audio path, or any running-state behaviour is touched.

This is deliberately the pragmatic fix, not the dignified one. As @dingodoppelt noted, QApplication::quit() here is a workaround, not the clean design — the underlying cause looks like threads not being torn down in time, and the proper solution is likely a signals/slots-based shutdown (the discussion in #3372 / #3402 / #3654 is the right home for that). The trade-off this PR offers is: KDE users get a server that actually exits today, at the cost of a line everyone agrees is a placeholder.

So — if you would rather hold out for the real, official, proper shutdown refactor, please just close this PR. No offence taken. It is here purely so the option of shipping the known-working one-liner now is on the table, in case that is preferable to leaving a three-year-old "the app won't quit" bug open while the larger design is worked out.

Testing note, stated plainly: the change compiles cleanly on desktop Linux (Qt 5). I have not reproduced the original KDE hang on my own setup, so I cannot personally confirm the fix on affected hardware — its credibility rests on @dingodoppelt having tested exactly this call and reported it resolved the problem. A confirmation from anyone who can reproduce the original bug would be welcome before merge.