scheduled_prompts: fix worker doc nits (argus review on #454)

hive-c0re/src/scheduled_prompts_worker.rs

@@ -24,8 +24,16 @@
 //!     `operator` describing the schedule + target + reason,
 //!  3. continues fanning out to the other (live) targets.
 //!
-//! Transient broker errors (sqlite lock contention, etc.) are
-//! logged and retried on the next tick.
+//! Transient broker errors (sqlite lock contention, etc.) get
+//! the per-target `last_result` annotated AND a `tracing::warn`,
+//! but the post-fire bookkeeping treats the row the same way it
+//! does on a clean fire:
+//!  - **recurring** rows re-arm — the next interval slot tries
+//!    the broker send again, so transient errors self-heal.
+//!  - **one-shots** delete unconditionally after their single
+//!    fan-out pass; a broker failure on a one-shot is NOT
+//!    retried (the operator advisory + last_result are the only
+//!    audit trail).
 
 use std::sync::Arc;
 use std::time::Duration;
@@ -170,9 +178,16 @@ fn fire_schedule(coord: &Arc<Coordinator>, schedule: &Schedule, now: i64) {
 }
 
 /// Snapshot of live container names for the missing-target check.
-/// Returns an empty set on lifecycle errors — we fail-open then
-/// (every target gets through) and the broker rejects unknown
-/// recipients downstream.
+/// Always seeds the manager name (which is always reachable);
+/// adds every live nspawn container that matches the `h-` prefix.
+/// On `lifecycle::list` failure the set stays at just the manager
+/// — fail-CLOSED, meaning every non-operator/non-manager target
+/// looks missing this tick and gets the same treatment as a
+/// genuinely-destroyed agent: operator advisory + per-target
+/// `last_result` annotation + skipped delivery. Recurring
+/// schedules recover automatically on the next tick (the lifecycle
+/// listing usually works); one-shots that land on this window
+/// lose their single delivery. Logged at `warn`, not propagated.
 fn known_agents(_coord: &Coordinator) -> std::collections::HashSet<String> {
     // `lifecycle::list` is async; the worker tick is sync. Use the
     // blocking variant via a small `tokio::runtime::Handle::block_on`