feat(events): hand a meeting to a new host (PPT-2640)

[chillfox]

Scenario 1 of PPT-2375 — "the 'Booking Host Changed' notification should be sent to the original host" — and the fix for PPT-2640, "Host Details page displays old host name after editing".

Why it wasn't working

Changing the host of a calendar event was a no-op. #update never read changes.host: it re-derived the host from the existing calendar event, wrote the edit back to that mailbox, and re-read the organiser from the response into EventMetadata#host_email. So the old name reappeared (PPT-2640) and the emitted signal had host == previous_host_email, which is why the visitor mailer never told the original host.

That is a real Microsoft restriction — organizer is not in the updatable properties for PATCH /events/{id} and there is no transfer-ownership API — but it was being hidden rather than handled.

Handing a meeting over

A changed host now does what a person does in Outlook: the meeting is cancelled and sent again from the new host's calendar. The old event goes first, because a resource mailbox declines an invitation that clashes with itself. If the re-send fails the original is restored on the old host's calendar and the request errors, rather than leaving the meeting cancelled and the room empty.

The meeting keeps its identity in PlaceOS — the same metadata record follows it onto the new event id and ical uid, so visitors, check-in state, linked bookings and extension data all survive.

Guards, because this is destructive:

• recurring meetings are refused with a 400 — every occurrence and exception would have to be rebuilt, and a person hits the same wall in Outlook,
• a host matching the requesting user is ignored — front ends fall back to the current user when they cannot resolve the organiser, which would otherwise silently steal meetings,
• can_create? is enforced against the new host's calendar, as it is for event creation.

⚠️ The response carries a new id and ical_uid, and attendees get a cancellation followed by a fresh invitation. The front end needs to re-read the event after a save (front-end ticket to follow).

Who is hosting, on every signal

host on staff/event/changed, staff/guest/attending and staff/guest/checkin is now whoever is hosting; the mailbox owner is reported separately as organiser_email. That makes the visitor mailer's existing behaviour correct without changes: the previous host gets the reassignment email, the new host is filtered out of visitor emails, and check-in notifications reach the current host.

extension_data.host_override is the non-destructive variant — it records who is hosting while leaving the meeting on the organiser's calendar, which is what deployments that book rooms as a service account (room_as_host / force_host) want. Send an empty string to clear it. Whoever it names is added to the meeting so it reaches their calendar.

Changes in Outlook still win where they should: if the calendar reports a different organiser, a stale PlaceOS reassignment is dropped and whoever was hosting is reported as the previous host, so they are told.

Testing

10 new specs: reassignment via both routes, the requester guard, clearing, transfer (cancel + re-send, metadata follows, room re-invited), recurring refused, the new host reaching the calendar, an organiser change from the calendar dropping a stale reassignment, and interaction with a room move.

./test — 251 examples, same 5 failures as master (all pre-existing). Format and ameba clean.

Stacked on #382. Pairs with PlaceOS/drivers#621.

[naqvis]

LGTM