[platform] Recurring automation ticks re-delivered 3-30x per batch to live sessions (cross-type, multi-day)

No repository file, test, or entry point is identified; start by locating the upstream message-dispatch and recurring-automation delivery path. Reproduce or inspect duplicate deliveries across automation types, then verify that each (automation_id, slot_ts) is delivered once or exposes a reliable idempotency signal, with telemetry if that is the chosen resolution.

Summary

Recurring automations (cron-style scheduled prompts) are being re-delivered to live sessions multiple times per tick. Observed continuously across several days (2026-09-16 → 09-25):

• Same tick / same minute delivered 3–30× per batch, batch-internal gaps of 8–20 seconds;
• A single inbound message can contain 30+ verbatim copies of the same scheduled instruction;
• Affects multiple sessions and multiple automation definitions; also observed for non-heartbeat message types (a whole advisory report got re-delivered the same way), so it is not specific to one automation's content.

Local-side forensics (all clean)

• crontab -l: no related entries;
• launchctl: the automation runs as a single launchd instance (no duplicate daemons);
• The scheduled script itself is deterministic and idempotent — every delivery logs ok=true, repeated ticks short-circuit as already-done.

⇒ The duplication is not produced on the local machine. Root cause appears to be concurrent dispatch in the upstream delivery layer (multiple host-side workers picking up the same scheduled slot).

Impact

1. Massive token/context waste: the vast majority of session messages become heartbeat noise;
2. Statistics corruption: any acceptance/coverage metric counted from tick delivery must de-duplicate by timestamp (same tick ≥5 min apart counts once) — raw counts are unusable;
3. Cross-type spread (advisory reports re-delivered verbatim) suggests the duplication happens at the message-dispatch boundary, not in automation definitions.

Requests

1. Upstream delivery layer should de-duplicate per (automation_id, slot_ts) — deliver once per slot, or coalesce concurrent workers;
2. Or expose an idempotency key / delivery contract so clients can reliably detect re-delivery;
3. Or at minimum, expose per-automation duplicate-delivery telemetry so affected users can confirm the diagnosis.

Happy to provide sanitized timestamp logs if useful.