todo: browser notifications for approvals / questions / operator msgs

pure frontend — Notification API + existing /api/state and
/messages/stream signals. Caveats: secure-context requirement
(HTTPS or localhost), per-browser permission grant. Includes a
sketch of the implementation: request-permission button, count
deltas on refreshState, SSE hook on operator-bound sends,
localStorage 'muted' toggle.

TODO.md

@@ -44,6 +44,30 @@ Pick anything from here when relevant. Cross-cutting design notes live in
 
 ## UI / UX
 
+- **Browser notifications for operator-bound events.** Dashboard
+  pings the OS notification center when (a) a new approval lands
+  in the queue, (b) a new `ask_operator` question is queued, (c) a
+  broker message is sent `to: "operator"`. All three data sources
+  are already in `/api/state` + `/messages/stream` so this is
+  pure frontend. Sketch:
+  1. Small "🔔 enable notifications" button somewhere (header
+     or near the inbox section). Clicks call
+     `Notification.requestPermission()`. Hide once granted.
+  2. Track last-seen counts in the JS app
+     (`approvals.length`, `questions.length`). On
+     `refreshState`, if the count went up, fire
+     `new Notification(...)` per new item.
+  3. SSE handler for `messages/stream` fires a notification on
+     `kind === 'sent' && to === 'operator'` (already triggers
+     `refreshState`; just adds a notify call alongside).
+  4. Notification body links back to the dashboard (`onclick →
+     window.focus()` + section anchor).
+  Caveats: Notification API requires a secure context (HTTPS or
+  localhost). Most operators access via LAN / Tailscale — works
+  fine for localhost forwards, otherwise needs a TLS cert in the
+  module. Persist a per-browser "muted" toggle in localStorage so
+  the operator can silence without revoking permission.
+
 - **Terminal: `/model` slash command.** Operator-typeable model
   override from the terminal. Depends on the model-override work
   above; once an override mechanism exists, wire a `/model <name>`