feat(desktop): notify on new critical items; keep running in the tray; start at login (Phase 4)

[ibuilder]

Roadmap Phase 4 accepts on "app runs in tray, updates the hotlist live, notifies on new 🔴 items, survives reboot as a service." The tray and the live hotlist existed. Notifications didn't, closing the window quit the app, and nothing started it at login.

What changes

Critical-item notifications

When the hotlist gains an act-today item, Osprey raises an OS notification, once per item.

• The decision is a pure function, alerts.ts. The shell only delivers.
• Notice deadlines lead with "Notice deadline:", because they're the items that can waive a claim.
• The first time a device sees a project, existing items are recorded without alerting, so opening the app doesn't produce one notification per item already on the list.
• Alerted ids are remembered in local storage (bounded to 500 per project), so a restart doesn't repeat alerts.
• A burst is capped: three individual alerts, then one summary ("N more items need you today").

The notification is raised from a Rust command (notify_critical) that calls the notification plugin. The webview doesn't need the plugin's JS permissions, so this opens nothing new to page script.

Background presence

• Closing the window hides it to the tray; Osprey keeps running. An agent that stops when its window closes isn't always-on, and the alerts would silently stop. Quit stays in the tray menu, and a left click on the tray icon reopens the window.
• Start at login: a new account → On this computer toggle, through the autostart plugin (a login item on macOS, the equivalent on Windows and Linux). A login launch passes --background, so Osprey starts in the tray without opening a window.
• The toggle shows what the OS reports after the change, not what was requested, and only renders inside the desktop shell.

Tests

alerts.test.tsx:

• first sighting is recorded silently
• a new critical item alerts exactly once
• non-critical buckets are ignored
• the notice-deadline wording
• burst summarising
• persistence across restarts
• HotlistView raising exactly one notify_critical when the live socket delivers a new critical item, and none on the initial load
• the start-at-login toggle, including that it is hidden outside the shell

Verification

• Frontend: tsc is clean, and all 65 tests pass.
• Rust: cargo fmt --check and cargo clippy -D warnings, with the new tauri-plugin-notification and tauri-plugin-autostart crates (results below).

Not verified

Nothing here has run inside a built app. No test shows a real notification or registers a real login item; CI never launches the desktop app. On the next release, check on a real machine that:

1. a new critical item raises an OS notification;
2. closing the window leaves Osprey in the tray;
3. the start-at-login toggle survives a sign-out and sign-in.

🤖 Generated with Claude Code