Rename the venue drawing to the venue map, since it is geometry and not a picture

The document the picker fetches for a hall is called its drawing: VenueMapBuilder::drawingUrl(), drawingDocument(), drawingCacheTags(), and the prose in docs/venue-map.md.

It is not a picture. It carries the sprite ids, the grades that make the legend, the sections, and every place with its coordinates, grade, printed number and accessibility flag. It is the hall's inventory expressed as geometry.

The picture is a different thing entirely and already has its own name and its own URL: the artwork, the background SVG served from the file's own path with its own version stamp. So there are two documents, one genuinely a drawing and one not, and the one that is not is the one called drawing. Anybody reading drawingUrl() for the first time reasonably expects the SVG and gets seat coordinates instead.

The name is map

Map, because a map is a representation of where things are, which is exactly what this document is. It also draws the distinction the code needs: the artwork is the illustration, the map is the geometry. "Drawing" fails precisely because it sounds like the illustration.

And because everything around it already says map. VenueMapBuilder, the venue_map library, the ysm- class prefix, the route /booking/venue-map/{venue}, VenueMapController, docs/venue-map.md, and the payload key the page already names, mapUrl. Naming the document anything else would drag all of that behind it; naming it map makes the vocabulary consistent by moving three methods.

What moves

• VenueMapBuilder: drawingUrl() to mapUrl(), drawingDocument() to mapDocument(), drawingCacheTags() to mapCacheTags(), and the VERSION comment that explains what the entries hold
• the cache id fragment venue_map:drawing:, which means bumping the entry version so nothing is read back under the old shape
• the prose in venue-map.js and in docs/venue-map.md that calls it a drawing, plus the French translation of anything user-visible
• test names and their docblocks where they say drawing: VenueMapFetchTest, VenueMapVersionTest, VenueMapCacheControlTest, VenueMapEndpointTest

The route, the library, the class prefix, the builder and the payload key all stay exactly as they are, which is the point of choosing this word.

Care

Pre-1.0, so no compatibility layer and no deprecation: the old names go in the same commit as the new ones. Bumping the entry version retires the cached documents rather than reading one back under a name that no longer describes it.

Worth its own change rather than folding into a caching MR, because it is mechanical and a reviewer should be able to see that it is only a rename.

The payload keys move too

The page names two URLs and neither says what is at the end of it: mapUrl returns JSON geometry, backgroundUrl returns an SVG, and nothing in either name distinguishes them. That is the same confusion as the drawing, one level out.

The test that decides it: put the URL in the address bar and see whether the name told the truth. backgroundUrl passes, since the browser renders the SVG and you do see the artwork; it is renamed to artworkUrl only because background names where the thing sits rather than what it is, which the code's own prose already fixes by calling it the artwork. mapUrl fails outright: you get a wall of JSON, not a map. It promises something to look at and delivers data to a program.

So mapUrl becomes mapDocumentUrl. Document is already this codebase's word for a payload something fetches: the method that serves this one is drawingDocument(), and the availability work in #3615840: Serve the seat map's availability as a shareable cacheable document, and carry the visitor's own state in a cookie calls its output the availability document throughout. Nobody reads *DocumentUrl as a page to browse, and unlike mapDocumentUrl it claims nothing about the encoding, so it cannot go stale if the format ever changes. mapDataUrl was the weakest of the three, since everything in a payload is data.

Considered and rejected: mapGeometryUrl, which is the most literally accurate but describes the contents where a URL name should describe the role; and mapInventoryUrl, which matches the producing method VenueMapBuilder::inventory() but reads as stock in a booking system and would collide with availability, the one thing this document deliberately does not carry.

That means VenueBackgroundUrl and the map_background field are in the same conversation. The field is stored configuration and renaming it is a schema change, so it stays out: this issue renames what the page and the map say to each other, not what the venue stores.