hive-c0re: deliver scheduled prompts via push_todo, not a broker message

docs/approvals.md

@@ -203,6 +203,22 @@ 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.
 
+### Scheduled prompt delivery: todo, not a broker message
+
+An agent target's delivery is `push_todo` (`Coordinator::push_todo`,
+`docs/coordinator.md` covers the mechanism generally), not a broker
+`Message` — a scheduled prompt wakes its target with a todo instead of
+driving an immediate turn, by design. `key = "schedule:<id>"` per
+target gives `push_todo`'s own upsert-by-key dedup the job a
+now-removed `has_pending_with_body` broker check used to do: a re-fire
+of the *same schedule* against a target that hasn't reviewed the last
+one collapses into that one todo instead of stacking up.
+
+**`operator` is the one exception** — it's a valid schedule target but
+has no in-container todo inbox, so it keeps the original broker
+`Message` path (the dashboard mirrors `to == operator` into its own
+pane, same as before).
+
 ### Missing-target failure
 
 When a target name doesn't resolve to a known agent (container
@@ -211,7 +227,9 @@ 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.
+   naming the schedule, target, and reason. This one stays a `Message`
+   regardless of target type — it's a to-operator advisory about a
+   broken schedule, not the schedule's own delivery.
 3. Continues fanning out to the other live targets.
 
 Transient broker errors (sqlite lock contention, etc.) get the same