No user accounts: settings are tied to one browser and operator actions to a shared API key #2128

What happens

CoreScope has no notion of a person. Two things follow from that:

• Everything a visitor sets up lives in one browser's localStorage: own nodes, favorites, the customizer, saved filters and per-page view preferences. A second device, a phone or a cleared cache starts from zero. feat: export/import json include favorite/claimed nodes #895 asked for favorites and claimed nodes in export/import for that reason.
• Operator actions are gated by one shared apiKey: geofilter save and prune, backup, perf reset. Anyone who needs to do one of them needs the key, and there is no way to give or take away that right per person.

Several requests depend on knowing who someone is, and cannot be built without it:

Proposal

Optional, off-by-default accounts, delivered in parts. Each part gets its own spec and PR:

• A. Foundation: email and password registration with a mailed activation link, sessions, roles user and admin, admin user management, mail through Brevo with delivery status. Admins can use the operator actions without the API key. PR: feat: optional user accounts (part A: foundation) #2129
• B. Settings sync: a logged-in user's settings follow them across devices. PR: feat: sync a logged-in user's settings across devices (part B) #2130 (builds on A)
• C. Admin dashboard: user statistics, audit-log viewer, admin-only views, server-enforced customizer restrictions (Feature Request: Make config settings to disable tabs in the customize modal #1508).
• D. Approval flows: a proposal and review mechanism, with Feature proposal: user-suggested shared hashtag channels with admin approval and revoke #2092 as its first consumer.
• E. Notifications: per-user subscriptions to node events (feat: foreign advert detection — alert when out-of-region nodes appear in local mesh #730, epic: alerting system — notifications for network events, health changes, and anomalies #775), sent through the same mailer.

C, D and E are not started. A and B are meant to be merged together: A alone gives a regular user an account but nothing to use it for.

Constraints both PRs keep

• Off by default. With no userManagement block in config.json the account routes are not registered and the interface shows no account control. The existing E2E suites run unchanged in that mode.
• Read-only analyzer database. cmd/server keeps opening the analyzer database read-only. Accounts live in a separate users.db, and a test pins internal/users as the server's only write path (AGENTS.md, read/write separation).
• Channel keys stay in the browser (feat: user-configurable channels in web UI + DB-backed message history #725). Channel keys, channel labels, decrypted messages and the API key are never synced. The server refuses them through a hard denylist that a test pins.

Specs

• A: docs/specs/2026-10-06-user-management-design.md
• B: docs/specs/2026-10-06-user-settings-sync-design.md