fix(events): keep event metadata when a meeting changes room (PPT-2375)

[chillfox]

Scenario 5 of PPT-2375, at source: a room move should be a change, not a re-invitation.

Why it happens

Event metadata is stored per room, so moving an event to another system did not find the existing record and started a fresh one. Everything hanging off the meeting was left behind on the old record and rebuilt empty:

• the attendee rows, so every visitor looked newly invited and was re-announced on staff/guest/attending — arriving downstream as a second, full invitation email,
• their check-in and induction state, silently reset by a room change,
• the event's extension data (catering orders, asset requests) and its linked bookings.

The metadata belongs to the meeting rather than to the room, so a move now takes it with it. With the attendee rows intact, previously_visiting is true for everyone already attending and the re-announcement stops on its own — the room change is reported by staff/event/changed, which is what the visitor mailer emails from.

The || changing_room clause and the elsif changing_room branch that forced the re-announcement (added 2020, long before change notifications existed) go with it.

Testing

New spec: after a move the same metadata record is reported against the new room with its attendees intact, staff/event/changed carries previous_system_id, and a visitor who was already attending is not announced again.

./test — 241 examples, same 5 failures as master (4 bookings_spec signal payloads + 1 all-day recurring clash e2e, all pre-existing). Format and ameba clean.

Stacked on #380. Pairs with PlaceOS/drivers#620, which fixes the duplicate email in the driver and does not depend on this.

[naqvis]

LGTM