[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.