feat(visitor_mailer): add the check-in code to change notifications (PPT-2375)

[chillfox]

Part of scenario 5 of PPT-2375. The duplicate visitor_invited.event QA reported is fixed by PlaceOS/staff-api#382, which stops the staff API re-announcing visitors when a meeting changes room. This is what remains: the change notification now has to carry the visitor's check-in details, because nothing else will.

Why

The kiosk link issued with a visitor's original invitation embeds a token scoped to the room the meeting was in. Move the meeting and that link is stale — and no fresh invitation is sent, by design. The booking_changed and event_changed templates therefore get guest_jwt, kiosk_url and the same inline qr.png attachment an invitation carries, built exactly the way the invitation builds them.

For a calendar event the QR names the room the meeting moved to; for a booking it names the asset, mirroring the invite flow's choice of resource_id / system_id.

disable_qr_code: true leaves the attachment off, as it does for invitations. Until a template references the new fields they are simply unused, though an unreferenced attachment may still surface in some mail clients — worth updating the templates alongside this.

Testing

5 specs: the fields and attachment on both changed templates, the QR contents pointing at the new room, disable_qr_code, template_fields exposing the fields to the template editor, and a guard that the host force-added to the attendee list by the staff API still doesn't get a visitor invitation.

./harness report --basic-render --verbose --tests=1 drivers/place/visitor_mailer_spec.cr passes; crystal tool format and ameba clean.

Earlier revisions of this branch also held and suppressed re-invites in the driver, as insurance against a staff API that re-announced everyone on a room move. staff-api#382 merged first, so that machinery would now only ever fire on the one visitor genuinely added during a move — dropping their invitation instead of sending it. It has been removed rather than carried.