A form naming a venue's configuration, pinning, section or grade offers every venue's, as a name to type

Problem

The venue form asks for a Default placement configuration and a Default pinning through autocomplete text fields, and the place form asks for its Section and its Grade the same way. Two things are wrong with that.

None of the four is scoped to a venue, and every record they name belongs to one. Editing the Grand Hall offers the Studio's configurations and pinnings; a place in the Grand Hall can be given a Studio section. These names describe a shape of room, so they repeat from hall to hall: two halls both have an Orchestre, a Cat. 1 and a Full house, and the two options are indistinguishable in an autocomplete. Nothing says afterwards which was picked, and what a wrong pick does is silent - the venue draws its map from another hall's configuration, or a place reports a grade no tariff of its production prices.

A venue holds a handful of each, and they are its own vocabulary rather than names an operator remembers, so a field to type into is the wrong device even where the value is right. The engine already says this of the allotment and the tariff class, which are lists to pick from for the same reason.

Steps to reproduce

1. Add two venues, and in each a placement configuration named "Full house".
2. Edit the first venue and type "Full" in Default placement configuration.
3. Both are offered, with nothing to tell them apart, and either one saves.

Proposed resolution

One entity reference selection handler, narrowing a reference to the venue in play, on all four fields. It reads the venue from the record being edited, whichever side of the reference that record is on: a venue's own form is the venue, and a place names one. Every one of these records is reached from its venue, with the venue prefilled, so the venue is always known; where it is not, the answer is no records rather than every record, which is what the two existing grade handlers already do.

The reference constraint asks the same handler as the widget, so another venue's record is refused on save rather than merely left unoffered, closing the hole for good.

The four fields become select lists. That also puts them in weight order without anything being said, because the pass that reorders weighted options works on any widget that has options, so a venue's configurations are offered in the order its own list was dragged into.

Remaining tasks

None. The narrowing, the widgets, the documentation and the French translation land together, with a kernel test per field that was seen to fail against unpatched code.

User interface changes

Four autocomplete fields become select lists, offering only the records of the venue in play, in weight order. A venue that already names another venue's configuration or pinning will be refused when its form is next saved, which is the fault becoming visible rather than a new one.

API changes

None. One new entity reference selection plugin, and no stored value changes meaning.

AI-Generated: Yes (Claude Code was used to investigate the fault, write the issue summary, and write the fix with its test. I reviewed both; the new test was confirmed to fail against unpatched code and to pass with the change.)