Issue #3615840: Serve the seat map's availability as a shareable cacheable document, and carry the visitor's own state in a cookie

Moves the seat map's availability out of the page and into a document any cache may keep, so a rush costs Drupal one answer per lifetime rather than one answer per viewer. See the issue for the full shape.

Landing in stages on this branch, each one green on its own, because the middle of it is a rewiring that is not safe to leave half applied.

Done

• VenueMapBuilder::availability() — the shared half only: taken, held, pool counts, tariff prices. No per-visitor field, and a kernel test asserts that over the whole serialized document rather than over the keys it happens to have today, so a field added later fails there too.
• GET /placement/{slot}/availability — a plain JsonResponse (core asks before overwriting Cache-Control on one of those, and overwrites a cacheable one outright), public or private decided by whether the anonymous role may book, exactly as the drawing endpoint decides it.
• Age, so the two lifetimes compose to one rather than two. The moving entry now carries builtAt, and the response reports how stale the answer already was; a proxy adds its own wait on top. STATE_VERSION bumped for the shape change.

Still to come on this branch

• A cookie carrying the visitor's own places and their corrections, written on mutation, read client-side — the HeldCookie pattern the calendar feed already uses.
• venue-map.js fetching the shared document and folding the cookie over it, which is where SessionPlaceRecord::correct()'s arithmetic goes.
• The page dropping its session context and max-age = 0, which is the actual win.
• Deleting SessionPlaceRecord, build() and withState(), and moving the kernel assertions onto state()/inventory().
• The pooled-area correction as a signed count delta.

Verified so far: 17 placement kernel classes green, phpcs clean, and the no-per-visitor guard was seen to fail when a mine key was added on purpose.