[BUG] Recurring CronCreate and ScheduleWakeup ticks accelerate to every few seconds after turns

Description

Recurring in-session scheduling re-fired shortly after each assistant turn instead of at the requested cron cadence, producing thousands of unexpected model turns while the sessions were otherwise idle.

Two long-lived seats showed the behavior on 2026-09-21 UTC:

• Claude Code 2.1.274, session 01a0adee-16e1-7982-ac9f-e15abb207b6c: a CronCreate schedule for 7,17,27,37,47,57 * * * * ran at about six times/hour until roughly 2026-09-20 17:00Z, then accelerated to 15, 44, and eventually 100+ times/hour. It received 2,821 tick prompts on 2026-09-21.
• Claude Code 2.1.276, session 01a0bfde-4e75-74c0-a388-be9233da07a4: a five-minute cron and a /loop 5m that re-issued ScheduleWakeup were both active. It received 3,058 tick prompts on 2026-09-21, including 456 ScheduleWakeup calls.

For both sessions, the unexpected prompts were isMeta=true, promptSource=system, appeared uniformly across clock minutes rather than on the requested cron boundaries, and had median gaps around 7-10 seconds. Many arrived 0.15-0.3 seconds after the preceding assistant turn ended. The advisor version did not change at the onset.

The stacked cron plus loop in the reviewer session may be an interaction rather than a single-feature fault, but the advisor session had only the cron schedule and showed the same acceleration. Please clarify whether a completed scheduled turn can accidentally retrigger its own recurring schedule, and whether recurring mechanisms are deduplicated when loops also request wakeups.

Impact

Across the two sessions this caused about 16,000 model calls and 9.8B tokens in one UTC day, almost entirely cache reads. Most ticks found no actionable work. We have removed model-side recurring mailbox polling from our prompts and switched to shell/event-driven waits, but the re-fire behavior remains a harness reliability concern for other scheduled uses.

Expected behavior

A cron-created task fires only on its configured cron boundaries. A loop/scheduled wake does not recursively reschedule itself after every assistant turn, and independently configured recurring mechanisms either remain independent at their requested cadence or clearly warn about stacking.