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

Reported at https://www.drupal.org/project/yoyaku/issues/3622036: the JSON availability endpoints look as though they have no access callback.

They have one, and always have. yoyaku_calendar.availability (/booking/availability/{yoyaku_resource}) carries _permission: 'view booking availability' since the initial commit, and _yoyaku_booking_channel: 'TRUE' since https://www.drupal.org/project/yoyaku/issues/3614926, which is the per-front restriction the report asks for. No route in the module is without an access requirement, and nothing shipped grants that permission to any role, so the feed answers 403 out of the box.

What was missing is the documentation. docs/calendar.md describes the feed purely as a cacheable public document (lifetime, tags, thundering herd) and names its permission 136 lines further down, under "What it does not do"; the channel requirement is not in that file at all. Read top down, the endpoint reads as ungated, which is how it was read.

• docs/calendar.md, availability feed. Name the permission and the _yoyaku_booking_channel requirement beside the endpoint, say that nothing grants the permission on install, and say that whether the anonymous role holds it also decides public against private on the answer.
• docs/calendar.md, per-slot booking page. Name the gate on the two documents the page fetches.
• docs/placement.md, venue map. The two endpoints accept administer yoyaku as well as place booking, which the picker page does not; the text claimed they need the picker page's permission exactly.

Documentation only, no code change.

AI-Generated: Yes (Claude Code was used to check the routes against the report and to help write this documentation change and this description. I reviewed it before posting.)