PlaceAssignment loads every place of the venue to propose a few seats

A quantity booking on a placed resource goes through VenuePlacementProvider::place(), which asks PlaceAssignment::proposeForCategory() for the best seats. That call loads every place of the venue as an entity, through PlaceAvailability::availablePlaces(), and then reads five scalars off each one: the id, the grade, the section, the printed row and the position. A hall of a few thousand seats is hydrated in full to choose two.

Nothing downstream needs the entity. place() keeps only the place id and drops the object, and the only other reader takes the row and the position to decide whether to warn that a party was split up. The authoritative allocation is the PlaceBookable constraint re-checking one place by id under the row lock, which is unaffected.

The fix is a set-based read: one query returning those five columns for the free places a category may fill, ordered in house order by the database, with no entity hydration at all. PlaceAvailability already owns the SQL expression of the placed/pooled/closed rule that such a query needs, so the read belongs there beside the other aggregates.

A latent bug goes with it. availablePlaces() sorts in its entity query, but loadMultiple() does not preserve that order once any entity comes from the cache, so the fallback that slices the first N eligible places picks them in an undefined order. Ordering in SQL settles it.

Correction: this issue was originally filed claiming the work happens inside the slot lock. That is wrong. BookingComposer::compose() runs to completion before BookingManager::holdGroup() opens its transaction and takes the row locks, so the proposal holds no lock and blocks no other booker. The cost is latency and memory for the booker making the request, which is why this is Normal rather than Major.