[m-wilkowski]

Problem

Logitune reads the desktop's light/dark preference once, at startup, through the XDG desktop portal. If the desktop switches later (GNOME's dark style toggle, or tools like darkman that switch at sunset), the window keeps the theme it started with until the app is restarted. Since logitune usually starts with the session and lives in the tray, in practice the window is often in the wrong theme.

Changes

• New SystemColorScheme class in src/app/services/ that wraps the portal: readDark() replaces the inline Read call in main.cpp, and it listens to the portal's SettingChanged signal for org.freedesktop.appearance / color-scheme.
• main.cpp applies the new value when the signal arrives, through the same Theme.dark assignment used at startup.
• A theme picked in Settings still wins: the live update only applies while theme/dark is not saved, the same rule startup already follows.
• GNOME sends each switch twice, so repeated values are dropped.
• tests/test_system_color_scheme.cpp: value parsing (dark, light, no preference, nested QDBusVariant, non-numeric), signal emission, repeated values, and unrelated settings being ignored.

No UI changes.

Testing

• logitune-tests: 760 passed, 1 failed (HyprlandDesktopFocus.ActiveWindowEventEmitsFocusSignal, the existing HyprlandDesktopFocus.ActiveWindowEventEmitsFocusSignal fails when a firefox .desktop entry is installed #160, fails the same way on master). logitune-tray-tests 9/9, logitune-qml-tests 72/72.
• Fedora 44, GNOME 50 on Wayland: switching org.gnome.desktop.interface color-scheme between default and prefer-dark while logitune runs flips the window both ways within a few milliseconds, once per switch.

[mmaher88]

Nice, small, and it works on our Qt 6.4 floor because it uses the portal signal rather than QStyleHints. Heads-up: #171 (keep running with the window closed) touches the same spot in main.cpp and makes the window optional. applyDark returns early when there's no root object, so after #171 lands, a theme switch while the window is closed would be lost. We'll sort out the ordering on our side. If this ends up rebasing onto #171, please route the update through MainWindowController (or a C++ dark property that Theme.qml binds to) instead of rootObjects().first(). Separately, a "Follow system" option, so users can return to live following after touching the toggle, would be a good follow-up.