Demo Availability

Pooled, live, UTC half-hours across every accepting host.

HOST-SIDE, NOT VISITOR-SIDE. tz is validated here -- a malformed zone is a 422 the page can show next to the field before ever drawing a grid it cannot render dates for -- but it does not change WHICH slots exist. availability.py's own module docstring explains why: each host's window is read in THEIR zone, because that is what keeps 9am 9am to them through a DST switch. The visitor's zone is a display concern the page applies to these same UTC instants after the fact.

NEVER NAMES A HOST. Every accepting member's slots are pooled into one undivided set of UTC instants (deduplicated on start/end); nothing in this response is keyed by, or traceable to, which principal offered which slot. See this module's own docstring for Frederick's quote.

A CONSTRAINING ATTACHED VP'S CALENDAR IS SUBTRACTED HERE TOO (_constraining_busy), not only at booking time -- otherwise this grid could offer a half-hour the booking re-check would then correctly refuse, landing the visitor on an unexplained 409.

An empty roster (nobody holds demos:accept and has accepting=true, or none of them could be verified live) answers {"slots": []} -- an honest empty grid, never an error, matching availability.slots_for's own "unfinished profile offers nothing" contract.