fix(cli,core): wake the parked login-wait daemon on sign-in

The login backoff had no wake-up path. A unit started at boot sits in
wait_for_session and reaches the ceiling within ~90s; the user then signs
in and `enable --now` is a no-op on an already-active unit, so the daemon
kept sleeping and the mount appeared up to a full interval late.

- service::enable_start now runs `enable` + `restart` instead of
  `enable --now`, so the GUI login and the tray's Connect interrupt the
  sleep immediately and still start a unit that is down.
- `pdfs login` restarts the unit when it is already active. It stays out
  of `enable` on purpose, so a headless setup driving `pdfs daemon` by
  hand is left alone.
- Lower the backoff ceiling from 60s to 15s. It is still an 80% cut in
  keyring/D-Bus wakeups (28,800/day -> 5,760/day) and it bounds the
  worst-case latency for paths that never touch systemd.

Also corrects the flat-3s-poll figure in the doc comment: 86400/3 is
28,800 checks a day, not 48,000.

crates/pdfs-core/src/service.rs

@@ -47,10 +47,18 @@ fn systemctl_query(args: &[&str]) -> bool {
         .unwrap_or(false)
 }
 
-/// Enable the service so it survives reboots/logins and start it now. Called on
-/// successful login.
+/// Enable the service so it survives reboots/logins, and bring it up now.
+/// Called on successful login.
+///
+/// `restart` rather than `enable --now`: the unit may already be active but
+/// parked in the daemon's login-wait backoff (`pdfs daemon` sleeps between
+/// keyring checks). `--now` is a no-op on an active unit, so the daemon would
+/// keep sleeping and the mount would not appear until the next poll fired.
+/// Restarting makes the new session take effect immediately, and starts the
+/// unit when it is not running at all.
 pub fn enable_start() -> bool {
-    systemctl(&["enable", "--now"])
+    let enabled = systemctl(&["enable"]);
+    systemctl(&["restart"]) && enabled
 }
 
 /// Stop the running mount without disabling it. Called by the tray's