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

Fixes the four unscoped references described in the issue.

VenueRecordSelection (new) narrows a reference to the venue in play. It reads the venue from the record being edited, whichever side of the reference that record holds: a venue's own form is the venue, and a place names one. Where the venue is not known, the answer is no records rather than every record, which is what ResourceVenueGradeSelection and PresetVenueGradeSelection already do. In practice it is always known: these types are managed inside their venue with no cross-parent collection, and every add form prefills the venue.

Applied to yoyaku_venue.default_configuration, yoyaku_venue.default_pinning, yoyaku_place.section and yoyaku_place.grade, all four of which become options_select. Weight order comes for free: WeightedOptionsHooks reorders any widget that has options.

Because ValidReferenceConstraintValidator builds the same handler, another venue's record is now refused on save rather than merely left unoffered. No programmatic writer is affected: nothing in the module calls validate() on a place or a venue, and the generator, the importer and the layout screens already work within one venue.

docs/placement.md states the rule under Managing a venue, and the one new string is translated.

Verification. VenueScopedReferenceTest covers what each field offers, the unknown-venue fallback, the refusal on save, and that each field is a list. All five methods were run against unpatched code and seen to fail, then pass. Ten placement classes exposed to the handler change pass. phpcs as CI runs it: 0. DrupalPractice: 0. phpstan: 0. cspell: 0 unknown words after the project dictionary.