Scheduled Tasks fire outside their cron window after app reconnects post-downtime (also affects Cowork's separate scheduler)

Summary
Scheduled Tasks (mcp__scheduled-tasks__*, recurring cronExpression tasks) and Cowork's own internal scheduler both fired outside their configured windows after the desktop app was closed over a weekend, then reconnected. The pattern looks like a stale-schedule catch-up burst that ignores weekday-only cron restrictions, rather than either (a) properly skipping a missed weekday-only run, or (b) deferring it to the next legitimate scheduled slot.

Evidence — three independent tasks, same ~2 minute window, all on a Sunday (2026-07-26), none of which have a Sunday schedule:

1. ghl-memory-write (Claude Code Scheduled Task, cron 15 21 * * 1-5, weekdays 9:15pm) — lastRunAt: 2026-07-26T11:25:11.621Z. The task's own run output logged a 1.61-day gap since its last legitimate run and flagged itself as firing "Sunday daytime, outside the weekdays-20:15 cron window."

1. revert-france-schedule-shift (Claude Code Scheduled Task, one-time fireAt: 2026-07-26T11:00:00Z) — lastRunAt: 2026-07-26T11:25:11.672Z (51ms after #1) and flipped to enabled: false as if it had completed. But none of its instructed steps had actually executed: the cron change it was supposed to make to another task never landed, no output was written to the files it was supposed to write to, and no log entry was produced. The scheduler recorded a lastRunAt for a run that never really happened.

1. ghl-memory-sync (Cowork's own separate scheduler, cron equivalent of weekdays 8:30pm) — logged a genuine, fully-executed run at 2026-07-26T11:27:13Z, 2 minutes after #1/#2, also on a Sunday outside its weekday-only schedule. Unlike #2, this one's actions did execute correctly — it's the "fired on a day it shouldn't have" symptom without the "phantom lastRunAt" symptom.

Why this matters

• Weekday-only recurring tasks should either not fire at all on a non-scheduled day, or if there's an intentional "catch-up on reconnect" behavior, it should be explicit and clearly logged as a catch-up run rather than looking identical to an on-time scheduled run (the task itself has no way to distinguish these, since it just gets invoked with no metadata about why).
• Separately, a one-time task can be marked lastRunAt/enabled: false (i.e. "done") without its instructed actions having actually executed — this is a second confirmed occurrence of behavior first seen 2026-07-13, where the scheduler reports completion with no corresponding session/actions.

Request
Please check the reconnect/catch-up dispatch logic for scheduled tasks (seems to affect both the mcp__scheduled-tasks__* mechanism and Cowork's own scheduler) for missed runs after the app has been closed. Either:
(a) fix it so a missed weekday-only run is properly skipped, not fired late on a non-scheduled day, or
(b) make catch-up behavior explicit and logged as such, and guarantee the task's instructed actions actually execute before lastRunAt/enabled reflect completion.