docs: migrate scheduled-prompts worker + dashboard-events design prose to docs

docs/approvals.md

@@ -142,6 +142,26 @@ One-shot rows fire once (if past due, on the next worker pass) and are deleted b
 
 `targets` is its own table (`scheduled_prompt_targets`) so partial cancellation flips a single row and the dashboard can show last-fired / last-result per recipient. Cancelling every target reaps the parent row on the next worker pass.
 
+### Missing-target failure
+
+When a target name doesn't resolve to a known agent (container
+destroyed, operator typo, etc.) the worker:
+
+1. Records `last_result = "no such agent: <name>"` on the
+   per-target row.
+2. Sends a single advisory `Message` from `system` to `operator`
+   naming the schedule, target, and reason.
+3. Continues fanning out to the other live targets.
+
+Transient broker errors (sqlite lock contention, etc.) get the same
+`last_result` annotation plus a `tracing::warn`, and then:
+
+- **Recurring rows** re-arm to the next interval slot — the retry
+  self-heals on the next worker pass.
+- **One-shot rows** are deleted unconditionally after their single
+  fan-out pass; a broker error on a one-shot is not retried (the
+  operator advisory and `last_result` are the only audit trail).
+
 ### Destroy semantics
 
 `HostRequest::Destroy { name, purge }` is the lifecycle tear-down,

docs/web-ui/shape.md

@@ -46,6 +46,14 @@
   ~200 broker messages wrapped in `{ seq, events }`) on the
   dashboard and `GET /events/history` (last 2000 `LiveEvent`s
   also wrapped in `{ seq, events }`) on the agent.
+  **One unified channel**: browsers cap concurrent SSE
+  connections per origin (~6 in Chrome). Using one channel per
+  domain would exhaust this budget on a live hive; dispatching
+  by `kind` on the client is a one-liner. Per-domain splits are
+  reserved for high-volume sub-streams most consumers skip (none
+  exist yet). The broker's intra-process channel stays separate
+  from the dashboard channel to avoid coupling `recv_blocking_batch`
+  (hot path inside the harness turn loop) to presentation concerns.
   **SSE multiplexing**: the dashboard uses a
   `SharedWorker` (`stream-worker.js`) to hold one upstream
   `EventSource` per URL. All same-origin tabs share this worker