[macOS] Active 25-minute heartbeat has a 41-minute next-run gap after schedule update, without a visible deferral reason

Environment

• Desktop app version from installed Info.plist: 26.901.51231 (build 8109)
• macOS 26.5.2, arm64
• Time zone: Asia/Shanghai (UTC+08:00)
• Existing thread-attached heartbeat; previously executed successfully.

Observed behavior

An existing heartbeat updated to a 25-minute interval did not produce a new monitoring turn within the expected interval. Read-only inspection of the persisted TOML and local scheduler database showed the automation remained ACTIVE and the interval remained 25 minutes, but the next scheduled timestamp was about 41 minutes after the update and 41 minutes 41 seconds after the last run.

Sanitized scheduler snapshot on 2026-09-09 around 18:51 local time:

kind: heartbeat
status: ACTIVE
rrule: FREQ=MINUTELY;INTERVAL=25
last_run_at: 1788948687344 = 2026-09-09 18:11:27.344 +08:00
updated_at: 1788948728222 = 2026-09-09 18:12:08.222 +08:00
next_run_at: 1788951188000 = 2026-09-09 18:53:08.000 +08:00

The TOML agreed with the database on ACTIVE status, recurrence and update timestamp. The Desktop log recorded a successful automation_update response at 10:12:08.237 UTC. The configuration was not reset or recreated during diagnosis.

Expected behavior / clarification requested

A 25-minute interval should have understandable scheduling semantics. If an update starts the interval from the update time, the next occurrence would be around 18:37. If an existing anchor, busy-thread deferral, jitter or another rule applies instead, please expose that reason and the resolved next-run time so users can distinguish intentional deferral from a missed heartbeat.

The automation_update view response available to the agent only said that an automation card was rendered; it did not return the scheduling timestamps as structured data.

Workflow leading to this observation

1. Run a recurring heartbeat attached to an existing local thread.
2. After a successful monitoring turn, update the same heartbeat to a 25-minute interval through automation_update (this workflow uses changing backoff intervals).
3. Later compare the saved recurrence, last_run_at, updated_at and next_run_at when no new monitoring turn appears within 25 minutes.

This is a single observed incident, not a confirmed deterministic reproducer. We have not established the scheduler's recurrence anchor or whether the target thread was busy at the expected occurrence. We also have not established sleep/wake involvement, and are not claiming the heartbeat will never run. The report is about the unexplained timing gap and missing diagnostic visibility, not a proven root cause.

Impact

Monitoring becomes difficult to trust: an enabled 25-minute heartbeat can appear overdue with no indication whether it was deferred, skipped or failed.

Related but not necessarily the same issue: #17893 (in that report last_run_at remained null; this heartbeat has previously run). No private project prompts, account details, thread identifiers or raw database/log files are included.

Start by reproducing the recurring heartbeat update workflow and comparing the persisted TOML, local scheduler database, and Desktop log timestamps. Determine the recurrence anchor and whether deferral, jitter, busy-thread handling, or sleep/wake explains the gap; done means the next-run time and its reason are exposed clearly, including through structured automation_update data.