Windows Desktop heartbeat miscalculates multi-rule RRULE schedules

[quiezent]

Summary

On Windows Codex Desktop, a heartbeat automation accepts and persists a multi-line iCalendar recurrence (six weekly inclusion rules) but the scheduler calculates an invalid next run and misses a valid included occurrence.

Reproduction

1. Create one ACTIVE heartbeat attached to an existing thread.
2. Configure a single weekly local-time recurrence for 00:30 on Tuesday through Saturday. The Scheduled Tasks clock correctly displays the next occurrence at 00:30.
3. Replace that one rule with six weekly inclusion rules representing these New York weekday checkpoints during U.S. daylight saving: 09:30, 11:00, 12:30, 13:00, 14:00, and 15:30 ET. The local-clock equivalents span Monday-Friday evenings and Tuesday-Saturday early mornings.
4. The update succeeds and the multi-line value remains persisted.
5. Observe the Scheduled Tasks clock and wait for the included 00:30 local occurrence.

Actual behavior

• The clock reported 05:30 as the next run, which was not among any of the six configured occurrences.
• At 00:33 local time, the expected 00:30 heartbeat had not reached the target thread.
• The scheduler did not reject the unsupported multi-rule input; it silently saved a schedule whose next-run calculation was incorrect.

Expected behavior

Either:

• support the union of multiple valid recurrence rules and schedule the earliest included occurrence correctly; or
• reject multi-rule input with a clear validation error.

Notes

A one-rule schedule and manual “Run now” both successfully reached the existing thread. This appears distinct from, but potentially related to, the Windows Desktop automation-dispatch reports in #16938 and #19011. No portfolio, account, local path, or session data is included here.

[quiezent]

Additional reproduction: DTSTART can also corrupt a single rearmed heartbeat

On Windows Codex Desktop, I confirmed a related failure while using the one-rule rearm workaround:

1. A heartbeat was rearmed for the next local Malaysia checkpoint (00:00 MYT / 12:00 ET) with a DTSTART;TZID=Asia/Kuala_Lumpur:... line followed by one weekly RRULE.
2. The update API reported success, but Scheduled Tasks showed “Next run: Today at 8:01 AM”—unrelated to the requested midnight checkpoint.
3. The expected 00:00 MYT run was missed.
4. Replacing the recurrence with a bare single RRULE (no DTSTART line) restored the clock to the intended next local checkpoint (02:00 MYT).

This suggests that, in addition to the multi-rule union bug, the Windows Desktop parser/next-run calculation may mishandle DTSTART when a chat heartbeat is updated. The UI should either honor the requested local start/recurrence or reject the input. I will use one bare local weekly RRULE at a time and verify the clock icon after each rearm.