Summary

• Wall-clock cron pipes (e.g. every day at 7am) were firing immediately on install instead of waiting for their next scheduled slot. A user reported creating a "morning brief" pipe at 5:39pm via chat — it fired 12 seconds later (scheduler: queuing pipe 'morning-brief' (scheduled)).
• Root cause at crates/screenpipe-core/src/pipes/mod.rs:3352: newly-discovered pipes had last_run = UNIX_EPOCH, so cron.after(epoch).next() returned a 1970-01-01 slot which is always <= now ⇒ fire.
• Same trap whenever the app was off across a scheduled slot — on restart the cron would catch up immediately instead of waiting.
• Fix: anchor the cron lookup at max(last_run, now - 5min) so we only fire when the most recent slot is actually within a small grace window. Stale missed slots are skipped; the pipe waits for the next future slot.

The 5-minute CRON_GRACE_WINDOW absorbs scheduler-tick latency (~1s) and brief sleep/wake cycles without firing stale catch-up runs.

Interval schedules (every 1h, every 30m) are untouched — those have always been "fire N seconds after last_run" semantics.

Test plan

• cargo test --lib -p screenpipe-core pipes:: — all 131 tests pass
• New regression tests:
  • test_should_run_cron_fresh_install_waits — newly-installed pipe (last_run = epoch) does NOT fire immediately
  • test_should_run_cron_stale_last_run_waits — pipe whose app was off for 3 days does NOT fire immediately on restart
  • test_should_run_cron_within_grace_fires — slot hit moments ago, last_run far in past → still fires
• Existing test_should_run_human_daily updated to use minute-precision cron so the slot is "right now" regardless of test wall-clock time
• Manual: install a pipe at 5pm with schedule: every day at 9am — verify it does NOT fire on install and DOES fire at 9am the next day