A booker who asked for a number is told a seat they never chose is taken, and hears about a repair they never asked for

PlaceBookable keeps a physical place booked at most once per slot, under the lock, and refuses with "This place is already taken for this slot." That sentence is right for the booker it was written for: someone who pointed at a seat on the plan and lost it by a moment. It is now shown to bookers who never pointed at anything.

Every line carrying a place goes through that constraint, and the engine composes places itself: a claim by quantity on a placed venue produces lines naming seats, and so does a rearrangement of what a booker already holds. To the constraint those lines look exactly like a click, so a booker who pressed a stepper is answered in the words of one who chose a seat, about a seat they have never seen.

What each path should say instead is not the same sentence. A claim by quantity failed for want of room, and room is what it should speak about. A move into a chosen area failed because that area could not take the party, and the area is what the booker named. A rearrangement of places the booker never chose should say nothing at all: it is a repair nobody asked for, the booker keeps every seat they had, and how their party sits has already been said by SeatingCloseness::message() on the claim that placed them.

What tells the two apart is already in the constraint's hands. place_chosen arrives in the same values and is already read a few lines earlier, to refuse a booker who tried to pick a seat in an area the house gives out. The lines the engine composes set it to FALSE explicitly.

Depends on #3617964: Refuse in the booker words: nine engine messages reach the page untranslated, naming entity ids, which separates what is thrown from what is shown, and is the seam a per-path sentence hangs on.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it before posting; there is no code on this issue yet.)