fix(linux): handle unavailable status notifier at startup

[harshach]

Summary

• keep the StatusNotifier tray service alive when LibrePods starts before the desktop tray host
• register the tray automatically when org.kde.StatusNotifierWatcher becomes available
• avoid aborting the whole application during a normal login-time race

Root cause

When LibrePods starts with --start-minimized during graphical-session startup, it can race the desktop shell. tray.spawn() then returns ksni::Error::Watcher(ServiceUnknown("The name is not activatable")). The unconditional unwrap() turns that recoverable condition into a Rust panic and, with panic = "abort", a SIGABRT core dump.

ksni already supports this startup case through assume_sni_available(true): it treats a missing watcher as temporarily offline, monitors its D-Bus owner, and registers the tray once the watcher appears.

Impact

LibrePods continues running during session startup and its tray icon appears once the desktop tray host is ready. Environments that genuinely lack StatusNotifier support retain the existing --no-tray option.

Validation

• reproduced and diagnosed from a systemd-coredump and journal panic at src/main.rs:148
• cargo check --locked
• git diff --check

This patch was prepared with assistance from OpenAI Codex after diagnosing the reproducible startup crash. I reviewed the change and its dependency behavior and ran the checks above.