The documentation describes the availability endpoints as cacheable documents and never names the permission and channel gate they carry

Thanks for the report. That route is gated today: yoyaku_calendar.availability, at /booking/availability/{yoyaku_resource}, requires the "view booking availability" permission, and since #3614926 it also carries a _yoyaku_booking_channel requirement, which refuses a resource the front being served does not offer. Nothing in the module grants that permission to any role, so the feed answers 403 until a site grants it deliberately, which is the step a public booking front takes for the anonymous role.

The other JSON endpoints are gated the same way: /availability/slot/{yoyaku_slot}/offers and /booking/slot/{yoyaku_slot}/basket require "place booking", the venue map endpoints require "place booking" or "administer yoyaku", and no route in the module is without an access requirement.

What the report does catch is the documentation. The availability feed section of docs/calendar.md describes the endpoint only as a cacheable document, names its permission 136 lines further down under "What it does not do", and does not mention the channel requirement at all, so read top down the endpoint reads as ungated. The merge request on this issue names the gate beside each endpoint instead.

AI-Generated: Yes (Claude Code was used to check the routes against the report and to draft this comment and the documentation change on the merge request. I reviewed both before posting.)