Issue #3616297: Offer an area whose places the house gives out

The third way a big hall offers a part of the house: the booker takes the Corbeille, the house gives each booking a place in it, and the ticket still says row F, place 12.

The rule the change turns on. PlaceAvailability::scopeOpen() answered one question for two: is this place in the place market, and may the booker point at it. assigned answers yes then no, so scopeOpen() widens to PLACED || ASSIGNED and a new scopePickable() answers the narrower half. Every count, candidate read, bound and constraint therefore picks an assigned area up with no arithmetic change.

Counted once. pools() stays pooled-only for the availability bound and the pool constraint. An assigned area's capacity is its places, which are already in the place counts, so counting a block beside them would promise every seat twice. AssignedAreaTest::testTheBoundCountsAnAssignedAreaOnce is that guard.

What a booker sees. The area is one block with a stepper, offered from the plan and from the Placement select on the booking page, both reading one list of offers. Its seats are drawn dim and inert so the booker can see where they will sit, and the seats they are given paint as their own. A click on such a seat falls through to the area's outline; hover or focus lifts the whole cluster. PlaceBookable refuses a place the booker chose in such an area, which is the authoritative rule behind the map not offering them, and it covers the relocate op and a request built by hand too. Stepping the block down gives seats back through giveUpFirst(), so it cannot strand a place.

Nothing new is stored. The line names its place; the place carries the section and subsection. section/subsection on a booking stay pool-only.

Renamed where the meaning widened: pools becomes areas in the map payload and its model (VERSION and STATE_VERSION bumped), poolTaken()/ poolAvailable() become areaTaken()/areaAvailable(), and the picker's ops answer areas. The readers that stay pooled-only keep their pool names, which is what keeps the double-count rule visible in the code.

Tests: AssignedAreaTest (12) and AssignedPickerTest (4) are new; the double-count guard was seen to fail against a deliberately wrong pools(). PoolOpTest, PoolPickerTest, VenueMapBuilderTest, VenueMapInventoryTest, PooledSectionProviderTest, SectionPoolBookableTest, AreaChoiceTest, PoolAvailabilityBoundTest, ConfigurationTest, ConfigurationSectionTest, SectionSettingsCacheTest and SectionTest were re-run green. Docs and the French translation ship with it.