fix: include buffer-overlapping bookings when prefetching bookings for slots

[rxits]

What does this PR do?

Fixes #29532

The slots endpoint can offer a time that booking validation will always reject. When a booking ends just before the requested slot range but its after-event buffer extends into it, the slot listing prefetch misses that booking entirely, so the buffer is never applied and the in-buffer slot shows as available. Picking it then fails with a 500 no_available_users_found_error.

The two paths diverge:

• Booking validation goes through getBusyTimes, which widens its bookings query by the largest configurable buffer (getDefinedBufferTimes(), currently 120 min) on both sides, precisely to catch bookings outside the range whose buffers fall inside it.
• Slot listing prefetches bookings itself in AvailableSlotsService via findAllExistingBookingsForEventTypeBetween using the raw requested range, and hands the result to getBusyTimes as currentBookings — which skips the widened query.

This PR applies the same max-buffer widening to the slot-listing prefetch, so both paths see the same bookings. The rest of the busy-time math already handles these bookings correctly once they are in the list (as @jckw noted in the issue, and confirmed by @GAURAV07C's analysis).

How it is tested

Added a getSchedule test reproducing the issue:

• Event type 1: 45 min with a 60-minute after-event buffer, booked at 04:00–04:45 UTC, making the host busy until 05:45.
• Event type 2: 60 min, no buffers. Slots requested with a range starting at 04:55 — after the booking ends, but inside its buffer.

Before the fix, the prefetch query (endTime: { gte: startDate }) excludes the 04:00–04:45 booking and the 05:30 slot is wrongly offered. With the fix it is hidden, matching what booking validation enforces. The test fails on main and passes with this change.

Also ran the full getSchedule.test.ts suite (37 passed), the slots router tests, and getBusyTimes tests — no regressions. Type checks pass for packages/trpc and apps/web.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. N/A — bug fix, no behavior contract change.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

[github-actions]

Welcome to Cal.diy, @rxits! Thanks for opening this pull request.

A few things to keep in mind:

• This is Cal.diy, not Cal.com. Cal.diy is a community-driven, fully open-source fork of Cal.com licensed under MIT. Your changes here will be part of Cal.diy — they will not be deployed to the Cal.com production app.
• Please review our Contributing Guidelines if you haven't already.
• Make sure your PR title follows the Conventional Commits format.

A maintainer will review your PR soon. Thanks for contributing!

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

rxits seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}