fix(calendar): RECURRENCE-ID exception handling + sync failure notifications

[icciaaron]

Summary

RECURRENCE-ID exception events (RFC 5545 §3.8.4.4) — used when a human moves or cancels a single occurrence of a recurring calendar event — were previously dropped silently. The original developer commented out the handling code and replaced it with a warning notification, causing:

• Modified occurrences (e.g. moved meeting) to disappear entirely
• Cancelled occurrences to remain active (original time still matched)
• A DB write per exception per sync cycle (notification spam)
• Cascading failures in time conditions and call routing

RECURRENCE-ID fix (IcalRangedParser.php)

Three code paths fixed:

1. parseRecurrences() fast path: Filter RECURRENCE-ID replaced timestamps from the recurrence array (matching what the non-fast path already does)
2. getEvents(): Include non-cancelled replacement VEVENTs as regular events with standard range checking. Drop STATUS:CANCELLED exceptions
3. getEventsNow(): Same fix for fast-mode AGI call routing

The fix leverages the existing _RECURRENCE_IDS lookup table that om/icalparser already populates during parseString(). The original occurrence is already removed from the parent series' recurrence list by the RECURRENCE-ID filter in parseRecurrences(). The replacement VEVENT simply needs to not be dropped.

Sync failure notifications (Calendar.class.php + Base.php)

• sync() now wraps processCalendar() in try/catch — one broken calendar no longer kills sync for all calendars
• Sync failures produce a critical admin notification (visible in the notification tray and email if configured)
• Successful sync clears any previous failure notification for that calendar
• buildCache() parse failures also produce a critical notification

Known limitation

RECURRENCE-ID;RANGE=THISANDFUTURE is not supported by the upstream om/icalparser library and remains unhandled. This affects <1% of real-world usage — Google Calendar, Outlook, and iCloud all use series-splitting instead.

Test plan

• Unit tests for timed RECURRENCE-ID events (moved, cancelled, unmodified)
• Unit tests for all-day VALUE=DATE RECURRENCE-ID events
• Unit tests for fast-mode getEventsNow() matching (4 scenarios)
• Independent code review (security, correctness, edge cases)
• Manual test on PBXact 17 with Google Calendar containing exceptions
• Verify admin notification appears when calendar sync fails

[icciaaron]

Hi @Akarsh04 @prasanthcode4 — could one of you take a look when you have a moment? This fixes a real-world sync issue we hit in production with Google Calendar exceptions (modified instances of recurring events being dropped). CLA is signed and the change is scoped. Happy to split or rework anything that doesn't fit your conventions.