Accept a proposed time from a guest of a meeting we organize

[brhellman]

The other half of COUNTER (#2926): when a guest proposes a new time, the organizer's mail client should be able to take it. A COUNTER arrives as an ordinary message with an attachment, so the header now recognises METHOD:COUNTER, shows the proposed slot (the attachment is the only place it exists - our synced copy still holds the original) with what already overlaps it (#2925) and offers Move event to this time, which rewrites DTSTART/DTEND on our copy - only the occurrence the COUNTER names, as an inline exception, when it names one - advances SEQUENCE once (#2923's bumpEventSequence), and lets the server re-send the invitation to every guest as it does for any organizer change.

Because accepting rewrites the meeting and re-invites everyone, nothing in the attachment is trusted for the decision. Its UID, ORGANIZER and ATTENDEE list are written by whoever sent it, and a UID is not a secret - it travels in the invitation to every guest and back in every reply, so a message carrying a known UID would otherwise be a one-click rewrite of the meeting from an address nobody invited. counterProposalProblem asks both questions of our own synced copy instead: the ORGANIZER must be this account or one of its aliases (only the organizer may revise a meeting, RFC 5546 section 2.1.4), and the message's From address must be on that copy's guest list (only an attendee may counter, section 3.2.7; a message with no sender fails this the same way). When either fails the proposal still renders, with a sentence saying why it cannot be applied here. A meeting Google has re-homed onto a shared calendar (ORGANIZER rewritten to ...@group.calendar.google.com) reads as somebody else's and is refused: a button not offered, not a meeting moved wrongly.

Stacks on #2926 and, for bumpEventSequence, on #2923; the branch carries a merge of the two.

Verified: counter-proposal-guard-spec (7 cases: guest of our meeting allowed, alias recognised as us, sender not a guest, message without a sender, someone else's meeting even with a guest sender, no ORGANIZER, unparseable copy refused rather than trusted) and 6 mounted header cases (the proposed slot shown and the move queued as one revision, one occurrence of a series moved, refused for someone else's meeting / a non-guest sender / no editable copy, an unapplicable proposal reported rather than thrown); 82 passing with the events package suites. 15 mutations across the guard and every header branch, plus 2 on the rebase, all red. Lint, prettier and tsc clean. Extracted from the calendar-scheduling branch; the guard was added there after review found the attachment being trusted (2026-09-16).

🤖 Generated with Claude Code