[SebastianKrupinski]

… array position

Summary

• Resolves: No e-mail notification sent when invitee is removed from event calendar#8953

• schedule() picked the "changed" VEvent via array_pop() on two unpaired flat arrays returned by EventComparisonService::findModified(), which could silently drop or mis-pair instances, and gated CANCEL/REPLY delivery on a comparison those methods never needed in the first place.

• Folded EventComparisonService into IMipService, matching old/new instances explicitly by UID + RECURRENCE-ID instead of array position

• Make schedule() method-aware: CANCEL/REPLY (which only ever consume the new instance) skip the old/new comparison entirely, fixing messages that iTip flagged as significant - e.g. removing an attendee, or a REPLY that only changes PARTSTAT - being silently dropped because the comparison found nothing "changed"

• Widen the REQUEST diff from 3 properties to the full set iTip's own significantChangeProperties tracks (RRULE/RDATE/EXDATE/STATUS plus SEQUENCE/LAST-MODIFIED and everything the email can show a diff for)

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[Rikdekker]

We tested this on a 35.0.2 instance (applied the apps/dav/lib + composer part; all hunks apply) with CalDAV-driven scenarios and all mail captured in Mailpit. Before → after:

• Organizer adds an attendee to the whole series: no mail to anyone → the new attendee gets a mail ✅. Small thing: the subject is "Invitation updated", because the instance exists in the old object. For an attendee who wasn't on the event before, "Invitation" would be expected.
• Organizer removes an attendee from the whole series: no mail → "Cancelled" ✅ (calendar#8953).
• Organizer removes an attendee from a single occurrence: that attendee now gets a mail ✅.

One side effect worth knowing about, though the cause is not in this PR: in every scenario that creates a new override (an attendee declines one occurrence, or the organizer adds or removes someone on one occurrence), TipBroker::parseEventForOrganizer flags significantChange for all attendees. That happens because the attendee's instance-key count grows, and because significantChangeHash is computed over the whole object. Before this PR, the old findModified comparison happened to drop some of those mails; now they are sent. Example: attendee C, who is only on occurrence 3, receives "Invitation updated" when attendee A declines occurrence 4. I opened #65971 with a fix for that in TipBroker, deciding significance per attendee over the occurrences they attend. With both applied on 35.0.2, every scenario mails only the affected attendee. It might be good to land the two close together. I've requested backports of #65971 to stable34 and stable35; it would be great to have this PR in both as well.

AI disclosure: the testing was done with the help of Claude Code (Anthropic). I reviewed and verified the results myself.