macOS: keep a plain vorta run alive after its window is closed

[ThomasWaldmann]

Description

Started from a venv (vorta, vorta --development, or the test suite) rather than from the app bundle, Vorta terminates about two seconds after its main window is closed instead of staying in the tray. The cause is outside Vorta: macOS sends a process that runs with the Regular activation policy (Dock icon) a quit Apple Event (aevt/quit, no sender PID) ~1.6 s after its last window goes away; AppKit turns that into applicationShouldTerminate: and Qt into a QEvent::Quit. The bundle has LSUIElement=1, runs with the Accessory policy, and is never asked. setQuitOnLastWindowClosed(False) has no say in this, and neither has QEventLoopLocker or NSProcessInfo.disableAutomaticTermination: (all tried).

This gives non-frozen macOS runs the bundle's policy right after the QApplication is created. Side effect, by design: a venv run no longer shows a Dock icon — exactly like the shipped app.

Related Issue

Found while testing #2555 from a venv; the behaviour is the same on master. No separate issue.

Motivation and Context

Developers testing tray behaviour from a checkout currently get a spurious quit whenever they close the window.

How Has This Been Tested?

• Reproduced with a 30-line PyQt6 script (tray icon + QMainWindow, setQuitOnLastWindowClosed(False)): hiding the window → applicationShouldTerminateAfterLastWindowClosed: (answered NO) → 1.6 s later an aevt/quit Apple Event → quit. Same on PyQt6 6.6.1, 6.10.0 and 6.11.0; gone with the Accessory policy.
• Real entry point (vorta --development <dir> from vorta-env, macOS 15.7): before, aboutToQuit 1.7 s after close() on both master and this branch's parent; with this change the app is still running 8 s after the close and opens the window again from the tray.
• New test tests/unit/test_application.py (macOS only) asserts the policy; pytest tests/unit: 265 passed, 7 skipped (macOS).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have read the CONTRIBUTING guide.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.

🤖 Generated with Claude Code