feat: mail notifications for watched nodes (user management part E)

[efiten]

Part E of #2128: a logged-in user watches nodes and gets one mail when a watched node goes offline, comes back, or reports a low battery. Admins can add instance events: a new foreign node, and an observer going offline or back. This covers the per-user mail part of #775.

Stacked on #2139 (part D, which builds on #2138). Review the commits after that branch.

The situation

A sysop learns that a repeater went silent, or that its battery is running down, only by opening CoreScope. #775 asks for notifications. Accounts (part A) now give a verified address to mail and a mailer with delivery status.

What this PR adds

Events. They use the instance thresholds, so a mail does not disagree with the node page:

• node.offline: silent for the role's healthThresholds window. Last heard comes from the packet store, and repeaters and rooms count relayed traffic (Active nodes are disappearing from the map #1598).
• node.battery: advert telemetry below batteryThresholds.lowMv, recovered at lowMv + 100.
• Admins only: foreign.new (once per node) and observer.offline.

Store. Schema v5 with notification_prefs, notification_watches and notification_state.

Server (only with userManagement.notifications.enabled)

• A notifier next to the janitor, every intervalMinutes (5). The evaluator is a pure function of watches, prefs, stored states and node snapshots.
• No burst after a restart or a new watch: a subject's first evaluation stores its state without mailing. The loop waits for the startup load. While ingest is stale (newest packet older than 30 minutes) the offline checks pause, and after recovery they wait one silent window.
• One mail per user per check. Limits: 20 per user and 100 per instance per rolling 24 hours, 50 watches per user. A change over a limit is recorded and never mailed later.
• Every mail has a one-click unsubscribe (List-Unsubscribe and List-Unsubscribe-Post). The GET only redirects to a confirm page, so link scanners cannot unsubscribe anyone. Node names are cleaned of control and bidi characters before they go into a mail.
• Routes: GET/PUT /api/account/notifications, PUT/DELETE /api/account/notifications/watches/{pubkey}, POST /api/account/notifications/watch-my-nodes (copies the synced "my nodes" list), GET/POST /api/notifications/unsubscribe. mailer.Message gains Headers.

Frontend. A "Notify me" toggle on the node pages, a Notifications section on the account page (#/account?section=notifications), an unsubscribe page, and the notification mail count on the admin overview.

Spec: docs/specs/2026-10-07-node-notifications-design.md.

Performance

Each check reads watches, prefs and states from users.db (one query each), the watched nodes from the analyzer DB in chunks of 500, and last-heard times from the packet store.

Measurement	Result
One check on our staging instance, 130,000 packets in memory, 1 watcher	6.9 ms, of which 0.93 ms holding the store read lock
Evaluator benchmark, 100 users with 50 watches each, 2,000 nodes	1.75 ms

No work is added to ingest, broadcast or any request path.

Verification

• internal/users and internal/mailer with -race; the cmd/server suite plus -race on the notifier tests; 74 new Go tests. The same Windows-only failure as noted in feat: admin dashboard with overview and audit log (user management part C) #2138 applies.
• sh test-all.sh exits 0; the XSS gate in diff mode passes.
• User-management E2E: 26 of 26 steps locally. With notifications off the new steps fail, so they do test the flag.
• On our staging and production instance since 7 October 2026.

Not in this PR

• Other channels (Discord, Telegram, webhooks). Detection is separate from delivery, so one can be added.
• The topology, RF and anomaly alerts of epic: alerting system — notifications for network events, health changes, and anomalies #775.
• If the whole server starts after a feed outage that already ended, the grace window is unknown and a watcher can get one wrong offline mail. The user guide says so.