Serve the venue background SVG as its own resource instead of inlining it per configuration

The venue's background SVG is inlined into the venue-map document rather than served as a resource of its own. VenueMapBuilder reads the file and pastes its markup into the payload, and the picker injects that markup into the page.

That has to happen today because the seat sprites are use references to a symbol defined inside the background file, and those resolve only within the same document. A linked image would draw the hall and leave every seat invisible.

It costs three things.

• The artwork is duplicated per configuration. The background belongs to the venue, but the document is keyed by venue and configuration, because a configuration decides which areas are sold as places. Measured on a hall of 1,422 seats: the as-drawn document is 259,754 bytes and the reduced-capacity one 186,233, and the SVG inside them is byte-for-byte identical at 19,938 bytes, which is 10.7% of the smaller document. A venue with five configurations caches the same drawing five times.
• The browser cannot cache the drawing at all. It arrives inside a JSON document that differs per configuration, so a visitor moving between two productions in the same hall downloads the artwork again each time, even though only the seat list differs (1,422 places against 947 in the measurement above).
• A background replaced on disk is never picked up. Because the markup is a copy inside a cached response, overwriting the file (an rsync deploy, say) changes nothing a visitor sees: the cache is retired by entity and list tags, and writing bytes over a file touches no entity. Re-uploading through the venue form does work, since the file entity is a cacheable dependency of the response. Verified by overwriting the bytes on disk and re-fetching: the response was unchanged.

The approach that addresses all three is to stop inlining it: give the background its own URL and let the browser cache it as an image, which also makes an on-disk replacement visible again. That means separating the sprites from the artwork, since they cannot keep living in a file that is no longer part of the document. The sprites are tiny, so inlining them alone (or fetching them once and injecting them) is the obvious direction.

Not started. The reason to write it down now is that the original framing of this issue was wrong: it said the file was read from disk on every request, which was true when it was filed and stopped being true with #3614076: Serve the venue geometry from a cacheable endpoint instead of drupalSettings. Once the map document became cacheable the read stopped mattering, and the duplication and the staleness became the real costs. The earlier note in this issue about a 1 MB memcache item limit was also wrong and is retracted; MemcacheBackend chunks oversize items.