ScheduleWakeup, session cron, and background-task notifications can all go silent across a context compaction (no catch-up, no delivery guarantee)

Environment: Claude Code CLI on macOS (darwin 25.6), long-running interactive session driven by /loop with self-paced ScheduleWakeup, a session-scoped recurring cron (CronCreate, */20 * * * *), and backgrounded Bash watcher commands (run_in_background: true).

Summary: During a ~103-minute window that coincided with a context compaction/resume, three independent wake mechanisms all failed to re-invoke the session simultaneously:

1. A pending ScheduleWakeup (re-armed every turn with ~1200s delay) never fired.
2. A session-scoped recurring cron (*/20 * * * *) that CronList still showed as armed produced no firings for the entire window.
3. Two backgrounded Bash commands (long-poll watchers) whose underlying work completed at 04:42:46Z and 04:46:49Z produced no completion notification. Their results were only discovered ~1h45m later by a manual status sweep.

The session was not deliberately busy for 103 minutes; a compaction/resume occurred in roughly this window, and we suspect either (a) scheduler/notification state being cleared or orphaned across compaction, or (b) missed fires having no catch-up combining with a long compaction turn.

Why this matters: the documented semantics make this failure mode hard to defend against from inside a session:

• Scheduled tasks fire only between turns, with no catch-up for fires missed while busy.
• Recurring tasks get jitter up to half the interval.
• Whether a pending ScheduleWakeup or session cron survives an in-flight compaction is not documented.
• Background-command completion notifications have no documented delivery guarantee.

Since all of these share one delivery channel (injection between turns), a single wedged/long turn or a compaction race starves every layer at once — including layers built specifically as backstops for each other. We have since built an OS-level (launchd) watchdog outside the session, but that only detects the silence; it cannot re-wake the session.

Asks / questions:

1. Should pending ScheduleWakeup timers and session-scoped crons survive a context compaction? If yes, this looks like a bug; if no, please document it.
2. Can CronList reflect actual scheduler health (e.g., last-fired timestamp) so "armed but not firing" is observable?
3. Are background-task completion notifications queued for guaranteed delivery on the next idle boundary, or can they be dropped (e.g., when completing during compaction)? Guaranteed-once delivery, or at least documentation of the loss modes, would help a lot.
4. Consider catch-up semantics (fire once if a scheduled time was missed) for recurring session crons used as liveness heartbeats.

Happy to provide timing details or logs.