Fix crash when quitting Nagstamon on macOS

[discostur]

On macOS Nagstamon reliably crashes with abort() when it is quit via Cmd-Q, the application menu or the dock. The crash report shows

QThread::~QThread() → QMessageLogger::fatal → abort
  ← QObjectPrivate::deleteChildren ← sipQTreeView::~sipQTreeView
  ← cleanup_on_exit ← atexit_callfuncs ← _Py_Finalize ← handle_system_exit

with four worker threads still sitting in QThread::exec().

StatusWindow.exit() is the only place where the worker threads are stopped, and it is wired to Nagstamon's own menu entries only (widgets/menu.py, qui/__init__.py). Cmd-Q and the dock quit the application straight through QApplication, so app.exec() returns with all threads still running, sip tears down the widget tree during interpreter shutdown and Qt calls qFatal() on the first QThread it destroys. On Windows and Linux there is no way to quit past exit(), which is why this only shows up on macOS.

QApplication.aboutToQuit is now connected to a new idempotent StatusWindow.shutdown_workers(), which exit() uses as well, so every way of quitting stops the threads. Three smaller things in the same code path came up while looking at it:

• the running flag of the workers is falsified before finish is emitted, as delete_server_vbox() and remove_previous_server_vbox() already do - otherwise a worker just schedules its next round via singleShot
• wait() for a thread to end is bounded and falls back to terminate(), so a worker stuck in a request cannot block the main thread until the 30 s socket timeout
• the treeviews are kept in a registry instead of being looked up through the layout, because sort_server_vboxes() drops ServerVBoxes that still own a running worker thread

Running from source, pressing Cmd-Q: before the change the process ends with exit code 134 and QThread: Destroyed while thread '' is still running, afterwards with 0. Quitting through the systray menu works before and after.

Also included

Two more macOS fixes that are small and sit in the same corner:

Keyring (#1159). Config.save_multiple_config() called sys.exit(1) whenever keyring.set_password() raised. On macOS the keychain regularly refuses with -25299 because the ACL of an existing entry does not accept a freshly built, unsigned binary, so saving a server killed the application every single time - the traceback in #1159 is exactly this. The two duplicated blocks moved into store_password_in_keyring(), which first tries to repair that case by deleting and recreating the entry, and otherwise switches the keyring off and stores the obfuscated password in the config file like it does without a keyring. Linux and Windows keep the previous loud failure. The general section of nagstamon.conf is written after the server configs now so a use_system_keyring turned off during saving actually ends up in the file.

Dock icon. hide_macos_dock_icon() passed NSApplicationPresentation* constants to NSApp.setActivationPolicy_(), which expects NSApplicationActivationPolicy*. NSApplicationPresentationHideDock happens to be 2, which as an activation policy means Prohibited: the application cannot be activated at all and its windows never get keyboard focus. Measured with the dock icon hidden:

policy	NSApp.isActive()	widget.hasFocus()
2 (Prohibited, before)	False	False
1 (Accessory, after)	True	True

Accessory is what is meant here. This should make the check_macos_dock_icon_fix_show/hide signal chain around every dialog unnecessary, but I left that in place rather than pulling on it in the same PR. Three pieces of dead code found next to it are removed: the unused AppKit import block in qui/__init__.py, the duplicated dialogs.authentication dock icon connections and the QMenuBar experiment in StatusWindow that was never added to a layout.

Tested on macOS 26.6.2 on Apple Silicon with Qt 6.11 and Python 3.14.

Fixes #1159

[discostur]

I could reproduce the abort locally and verify the fix, so here is the before/after.

Setup: macOS 26.6.2, Nagstamon from source with PyQt6 6.11, one server pointing at a blackhole address (http://10.255.255.1:9999) and update_interval_seconds = 1, so a status request is hanging in connect() when the quit arrives - three threads were sitting in connect in a sample of the process. Quit via the graceful quit which the dock and Cmd-Q use (NSRunningApplication.terminate()), which is the path that bypasses StatusWindow.exit().

master (1ae4048):

QThread: Destroyed while thread '' is still running
Abort trap: 6 -> crash report Python-2026-09-07-120557.ips

Triggered thread of that report:

abort
QtCore QMessageLogger::fatal(char const*, ...) const
QtCore QThread::~QThread()
QtCore.abi3.so sipQThread::~sipQThread()
QtCore QObjectPrivate::deleteChildren()
QtWidgets QWidget::~QWidget()
QtWidgets.abi3.so sipQTreeView::~sipQTreeView()

So it is exactly the case this PR is about: the worker QThread is a child of the TreeView, sip tears the widget tree down while the worker is still stuck in its request, and ~QThread() calls qFatal().

This branch:

quit finished after 2.1s
no "QThread: Destroyed while thread is still running"
no crash report

The 2.1s are the bounded wait for the threads which cannot be stopped; they are left to run into their socket timeout instead of being terminated, and the process leaves via os._exit() before anything can destroy them.