Rolling booking window creates unfairness across timezones

[ccwei]

With the current implementation, ROLLING/ROLLING_WINDOW compute boundaries in the booker’s timezone. That aligns with the booker’s local calendar but creates fairness issues: borderline slots can open earlier for some timezones than others. RANGE does not have this issue because it’s anchored to the event timezone and yields a single global instant.

Problem: lack of fairness across timezones
Because booker midnight occurs at different absolute instants, a borderline slot becomes available earlier for some timezones than others.

Concrete example
periodType = ROLLING, periodDays = 7, periodCountCalendarDays = true
Same real instant: 2025-09-14 10:00 UTC
Booker A: UTC−4 (local 06:00)
Booker B: UTC+9 (local 19:00)

Booker A (UTC−4)

1. Convert “now” to booker tz
   2025-09-14 10:00 UTC → 2025-09-14 06:00 (UTC−4)

2. Add 7 calendar days
   2025-09-14 06:00 → 2025-09-21 06:00 (UTC−4)

3. Take end of that local day
   2025-09-21 23:59:59.999 (UTC−4)

4. Convert to UTC (add 4 hours)
   2025-09-22 03:59:59.999 UTC

Boundary A = 2025-09-22 03:59:59.999 UTC

Booker B (UTC+9)

1. Convert “now” to booker tz
   2025-09-14 10:00 UTC → 2025-09-14 19:00 (UTC+9)

2. Add 7 calendar days
   2025-09-14 19:00 → 2025-09-21 19:00 (UTC+9)

3. Take end of that local day
   2025-09-21 23:59:59.999 (UTC+9)

4. Convert to UTC (subtract 9 hours)
   2025-09-21 14:59:59.999 UTC

Boundary B = 2025-09-21 14:59:59.999 UTC

Pick a slot at 2025-09-21 16:30 UTC:
A: before boundary → bookable
B: after boundary → not bookable

Same slot, same moment, different availability for different timezone.

Relevant code paths:
Bounds: calculatePeriodLimits, getRollingWindowEndDate, isTimeViolatingFutureLimit

I think the issue was introduced by this PR:
#15825

It switches the rolling check from event timezone to booker timezone to fix a UI issue. I’m wondering if this is the right way to fix it, or if we should consider other alternatives fix that wouldn't introduce this unfairness issue?