Notifications: opt-in architecture (shared enable flag, manager autostart, liveness) + evidence-based defaults

## Problem

The notifications settings panel (AwNotifySettings, shared thresholds for Android/desktop) is now reachable (ActivityWatch/aw-webui#972 fixed the 404), but on default **desktop** installs it is silently inert: neither aw-qt nor aw-tauri autostarts aw-notify by default, so thresholds get saved to `/0/settings/aw-notify` and nothing consumes them. Android is the opposite: NotifyWorker runs by default with baked-in alerts. Users have also reported not being able to turn the module on at all (#1175).

Product stance (Erik): notifications must be **opt-in — but with excellent opt-in defaults**, grounded in the intervention/nudging literature (positive reward framing over limit-nagging, timing at natural breakpoints, habituation avoidance), plus user-facing guidance on using them effectively. A research pass to derive those defaults is running separately and will be linked here.

## Design

**1. Opt-in flag in the shared settings key.** `enabled: false` by default in `/0/settings/aw-notify` — single source of truth for all platforms. Android's NotifyWorker honors the same flag (today it defaults on; unify to opt-in with a migration note).

**2. Managers read the flag at startup** and start aw-notify iff enabled. This is a one-directional manager→server read after server-up (managers already start/probe the server; no module management enters the server).

**3. Tray toggle for immediacy.** aw-qt/aw-tauri get an "Enable notifications" tray item that writes the flag AND starts/stops the module immediately. The webui toggle alone takes effect on next launch; the tray covers "I want it now". No webui→manager channel is introduced.

**4. Liveness without manager coupling.** aw-notify sends a periodic heartbeat to its own bucket (`aw-notify_`). The settings panel derives "running / not running (how to enable)" from bucket freshness — server-data-only, works on every surface including remote/Android.

**5. Module management stays OUT of the webui/server.** The server remains pure storage/query; process control stays with the managers. (If module control ever needs a remote surface it should be a manager-owned endpoint — out of scope here.)

**6. Target aw-notify-rs.** Python aw-notify is deprecated (ActivityWatch/aw-notify#16); the enable-flag + heartbeat work lands in aw-notify-rs (which already reads the shared settings API, ActivityWatch/aw-notify-rs#38). This also makes an always-run-silent fallback viable later if wanted, but the opt-in autostart design above doesn't need it.

## Evidence-based defaults (separate deliverable, feeds this issue)

- Default alert set + thresholds + timing rules with citations (JITAI, notification-fatigue/habituation, framing effects, implementation intentions)
- User-facing doc: how to use notifications for reward/nudging effectively; linked from the settings panel
- Ties into the existing reward-framing direction: achievements/streaks (ActivityWatch/aw-android#205), anomaly-detection alerts (ActivityWatch/aw-android#200)

## Prior work

- ActivityWatch/aw-android#201 (shared settingsStore + webui config surface — the panel this builds on)
- ActivityWatch/aw-android#196 (Android aw-notify support)
- ActivityWatch/aw-notify-rs#38 (shared config via settings API)
- ActivityWatch/aw-notify#8 (user demand for configurable category prompts)
- #1175 (module cannot be toggled on — the UX gap this closes)

## Rough scope by repo

| Repo | Work |
|---|---|
| aw-notify-rs | honor `enabled` flag; heartbeat bucket |
| aw-qt / aw-tauri | read flag at startup; tray toggle (write flag + start/stop) |
| aw-webui | enable toggle in panel; liveness display from bucket freshness; link usage doc |
| aw-android | honor shared `enabled` flag (migrate from default-on) |
| docs | user guidance page from the research deliverable |