Add a seating messages setting, so a house chooses when a booker is told how their party is sitting

Problem/Motivation

A booking that succeeds can still say something about where the party ended up. VenuePlacementProvider emits the whole SeatingCloseness ladder, worst last: side by side (silent); in the same row, but not all next to each other; in the same section, but not all in the same row; in the same section, but not all in the same part of it; could not be found together, so spread around the venue. Beside those, one more sentence for a party that moved into a row it was not in.

Every house gets all of it, and there is no way to ask for less. A house seating a standing room, or one where a row means nothing to a booker, is telling people about a distinction it does not have.

This is only about a booking that worked. The seat map's refusals are a different thing: a booker who clicks a place and is refused is always told why, and that stays true whatever this setting says.

Proposed resolution

One setting naming how far apart a party must end up before the booker hears about it: whenever anything moved, including a change of row (the default, which is today's behavior); when they are not side by side; when they are not all in the same row; when they are not all in the same part of the section; only when they are spread around the venue; never.

Each value is a floor on SeatingCloseness::getRank(), so the gate is one comparison and the options are the rungs a reader can look up.

SeatingCloseness::isWorthSaying() already exists and has no callers anywhere in the module or its tests. It is this question with the answer hardcoded to "anything short of side by side", so it takes the setting as an argument rather than a second method being added beside it.

"Your places are in another row now." is emitted twice, once on the placing path and once on the consolidation path, which builds its own UnitAssignment and computes no closeness. A condition written at the first site leaks at the second, so both ask the same method.

One read per claim, where the messages are built, rather than per place. VenuePlacementProvider already resolves AreaChoiceResolver and PlacementPartitions already resolves PartyAreaResolver, so the config object and the type and tenant entities are in the static caches by the time this asks.

Remaining tasks

Add the SeatingMessages enum and its resolver; declare the field and the config key with its schema constraint; gate both emitters; kernel coverage for the resolver ladder and provider coverage asserting silence at each rung; docs/seating.md; French for the new strings.

User interface changes

A select on the booking settings form beside "Let a booker choose an area". A row on the field rules screens of the resource type and the tenant, rendered by the existing subform with no new form code. A select on the resource form itself, in the placement group, starting out on Inherit.

The resource control is not optional. This summary first proposed declaring the field without form display options, so that only the tenant and the type could answer it. That is not a shape this codebase has: a field rule is a question an operator is asked, and ResourceFieldDefaultsTest holds every ruled field to appearing on the form its rule governs. The choice is between the whole ladder and a site setting with no ladder at all, and the ladder is worth its column.

API changes

SeatingCloseness::isWorthSaying() gains a parameter. It is public but has no callers, in or out of the module. New SeatingMessages enum and one resolver service.

Data model changes

A list_string base field on yoyaku_resource carrying RuledField::FOLLOWS, named in RuledFieldTest's inventory of followed fields, and a seating_messages key in yoyaku_placement.settings. Pre-1.0, so no update hook: the field arrives by reinstall like the others this cycle.

AI-Generated: Yes (Claude Code read the code, proposed this design and drafted this summary. I reviewed it before posting.)