Serve the venue geometry from a cacheable endpoint instead of drupalSettings

The picker receives its whole payload as drupalSettings, inlined in the page HTML. The geometry is roughly 200 bytes of JSON per seat, so a 2,000-seat hall ships about 400 KB inside every page and a 20,000-seat arena about 4 MB. That is larger than everything #3614038: Cache the venue place map: VenueMapBuilder loads every place of a venue on every request, inside an uncacheable form just saved, and it is paid by every visitor on every request, uncompressed in the document rather than in a cacheable subresource.

#3614038: Cache the venue place map: VenueMapBuilder loads every place of a venue on every request, inside an uncacheable form is the prerequisite: VenueMapBuilder now builds the venue's inventory as a slot-free, alter-free, language-split structure, which is exactly what an endpoint would serve. The shape is the model to follow: geometry cached per venue with the inventory list tags, and a small per-slot overlay carrying seat state and prices.

Worth doing in two steps, because only the second one carries risk.

Phase 1: the endpoint. Add the route serving the venue geometry as JSON with the inventory cache tags, on the model of the availability feed in yoyaku_calendar. Leave venue-map.js reading drupalSettings. Entirely server-side, covered by kernel and functional tests, and reviewable on its own with no change to the picker.

Phase 2: the bootstrap. Flip Drupal.behaviors.yoyakuPlaceMap to fetch, and reduce drupalSettings to the ids and the endpoint URLs. The diff is small: initPlaceMap(root, data) already takes the payload as an argument, so the rendering code never learns where it came from.

The risk in phase 2 sits in that one function rather than spread through the picker:

• once() marks the element before the data arrives. If attach becomes async, a failed or slow fetch leaves an element flagged as initialized and permanently empty, with no error and no retry.
• Behaviors re-attach on AJAX, and the picker re-initializes when it goes full screen, so the fetch has to be idempotent per map rather than per attach.

#3614039: Add FunctionalJavascript coverage for the place map and calendar JavaScript covers exactly those failure modes, so it is worth having in place before phase 2 lands. It does not gate phase 1. Note that the byte saving itself only arrives with phase 2, when drupalSettings stops carrying the geometry; phase 1 is groundwork.