Per-booker limits are not enforced at the hold: the places being asked for are not counted

Both per-booker policies answer by counting what is stored and comparing it against the allowance, and the engine judges a hold group before any line of it is written (above the slot locks and again under them). So each was short by exactly the places being asked for, and a click past the allowance was accepted and only refused at the checkout, holding capacity out of sale for a booker who could not complete.

The fix

• BookerPolicyBase::requestedLines() sifts the lines no saved booking stands for yet: the request. After the hold there are none, so nothing changes at any later checkpoint.
• SlotPerBookerLimit adds the places asked for on each slot to the summed quantity it queries.
• CrossResourceLimit unions the slots asked for into the distinct stored slots it counts.
• PolicyContext::evaluationLines() is new, for the one thing the manager's narrowing cannot express: a policy whose pool is declared wider than its host. cross_resource_limit counts across every resource sharing a shared_with name, so an attachment on one of them is handed a part of what it counts, and a single request taking a slot of two pooled resources showed one apiece to their two attachments. It narrows by the pool it declares.

Tests

Three new cases in OrderConstraintTest, each run against the unfixed code first: 3 places under a limit of 2, two refuges under a limit of 1, and two pooled resources in one request under a limit of 1. Every existing case in that class names the booker after holding, so these policies were only ever reached at Confirm, where every line is written and the arithmetic was already right.