Implement attendee counter-proposal storage

[TDannhauer]

Summary

• Persist attendee counter-proposals from EAS 16.1 MeetingResponse commands onto the Kronolith calendar via calendar/storeAttendeeProposal.

Motivation

When an iOS client proposes a new meeting time, Horde already parses ProposedStartTime/ProposedEndTime, validates disallow-counter flags, and sends METHOD=COUNTER mail to the organizer. Without storing the proposal on the server-side calendar event, Kronolith cannot:

• export proposed times on the next calendar Sync (so the device shows the proposal), or
• clear them later when the organizer declines (via ActiveSync empty proposed-time tags).

This change closes the inbound path: device → server storage → sync / clear on decline.

Changes

lib/Horde/Core/ActiveSync/Driver.php

In _meetingResponse(), after proposal validation and before sending COUNTER iTip mail:

• Call calendar/storeAttendeeProposal with event UID, attendee email, and proposed start/end.
• On failure: log a warning and continue with the existing reply/COUNTER flow (MeetingResponse does not fail hard).

test/Unit/ActiveSync/DriverMeetingResponseTest.php

Add targeted unit coverage for attendee proposal persistence in meetingResponse():

• assert the registry call is made when both ProposedStartTime and ProposedEndTime are present
• assert the registry call is skipped when counter-proposals are disallowed
• assert the registry call is skipped when the proposed start time is invalid

Dependencies

Requires horde/kronolith (storeAttendeeProposal and related counter-proposal APIs). Works together with horde/activesync (WBXML export/clear) and horde/imp (organizer accept/decline in webmail).

Test plan

• EAS 16.1: attendee proposes new time on iOS → proposal stored on server → calendar Sync includes ProposedStartTime/ProposedEndTime for attendee
• Organizer declines in IMP → attendee iOS calendar clears proposal after sync
• Proposal ignored when event has disallow-counter iCal property (unchanged)
• Accept/decline/tentative MeetingResponse without proposed times still works
• Add unit coverage for meetingResponse() proposal storage and skip paths

[Copilot]

Pull request overview

This PR adds server-side persistence of EAS 16.1 attendee counter-proposals during MeetingResponse handling, by calling into Kronolith’s calendar API so proposed times can be re-synced to devices and later cleared when declined.

Changes:

• In meetingResponse(), store ProposedStartTime/ProposedEndTime on the calendar event via calendar/storeAttendeeProposal.
• On storage failure, log a warning and continue with the existing reply/COUNTER email flow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Addressed in 5351198.