Fixes #16378

What it does

When a host reschedules a booking, the system now checks if any attendee is a Cal.com user and excludes their busy times from the available slots. This means the host can only pick a time that works for both parties.

How it works

The change adds a new step in the slot computation pipeline that runs in parallel with the existing data fetches:

1. Look up the original booking’s attendees via BookingRepository.findByUidIncludeAttendeeEmails
2. Resolve attendee emails to Cal.com users via UserRepository.findByEmails — checks both primary and verified secondary emails, case-insensitive
3. Fetch the guest users’ existing bookings in the reschedule date range via BookingRepository.findByUserIdsAndDateRange
4. Pass these as guestBusyTimes into getUserAvailability, where they get merged into the combined busy times array

The rescheduled booking’s own time slot is excluded from the guest’s busy times so it remains selectable.

Scope

• Only runs during host-initiated reschedule (not when attendees reschedule themselves, per @CarinaWolli’s clarification)
• Skipped for COLLECTIVE scheduling type where all participants’ availability is already checked
• No UI changes needed — unavailable slots are simply filtered out as usual

Files changed

Self-review notes

• Repository methods follow naming conventions (no entity name prefix, Include keyword for relations)
• Uses select everywhere, no include
• Case-insensitive email matching handles mixed-case addresses
• Guest busy times fetched in parallel with existing queries (no added latency on the happy path)
• The rescheduled booking itself is filtered out so its slot stays available

/claim #16378