feat: #3622067 A venue package carries only the layout, so a hall moved between sites arrives with its configurations and its pinnings to rebuild by hand

A venue package now carries the hall's configurations, and the reason it did not is corrected wherever it was written.

What the reason claimed, and what the schema says. The README said configurations "reference slots and categories that live outside the venue" and VenueExporter said "slots and tariffs this package knows nothing about". yoyaku_configuration carries a venue, a key, a label and a weight. yoyaku_configuration_section carries the configuration, a section, a subsection number, a mode, a pool capacity and a pool grade. Every reference is a section or a grade, both of which the manifest already exports keyed by machine key, which is how places re-resolve on import. Neither entity has a field naming a slot or a tariff.

Manifest version 5 adds a configurations key, written only when the venue has any, so a hall opened one way exports the file it always did. Each row is a configuration with its settings, one per area it decides about; a setting names its area and its pool grade by key, and omits subsection when it decides about the whole area. The versioning contract is unchanged: every key is optional, so a version 3 or 4 package still imports, and the bundled Auditorium example (version 3) still does.

Where a pinning stands. The old sentence was true of one thing and false of the other, so it is split rather than deleted. A pinning is venue-scoped exactly as a configuration is, but its pinned places are held for a yoyaku_allotment, which belongs to a production rather than to the hall, so a package cannot say what a pinning is about. The export command now warns about pinnings instead of configurations, and reports how many configurations it wrote.

Reading the settings back through getSettings() is deliberate: it returns the areas of one configuration in house order rather than in creation order, which is what keeps an export comparable to the package it came from. There is a test for that on its own.

Three tests in VenueIoTest: a full round trip asserting each setting resolved its area and its pool grade and that the manifest comes back identical, the house-order normalisation, and the absent key for a hall with no configurations.

One defect found by the round-trip assertion while writing this, and fixed here rather than shipped: reading a setting's fields through the generic field API returned the pool capacity as the string "40", because an integer field hands back what it stored. The export reads through the entity's own accessors instead.

Verified locally: VenueIoTest 13 tests, 512 assertions green; phpcs over the module at the job's own extensions, 1099 files, zero violations; phpstan level 5 from the module directory, [OK] No errors (after a clear-result-cache — a stale cache reported 94 class.notFound cascades in the one file that had changed, and the same file analysed alone was clean); cspell over the seven changed files, nothing outside the project dictionary.

Follow-ups this does not do:

• The bundled examples/auditorium-de-bordeaux package is still version 3 and names no configuration, so the example anybody imports first still shows a hall opened one way. Filling that in honestly means exporting the real hall now that the command carries them, rather than inventing settings for seventeen areas.
• https://www.drupal.org/project/yoyaku/issues/3622060 wants a demo hall that arrives as data rather than as an install hook, which is what this makes possible.

AI-Generated: Yes (Claude Code was used to check the configuration entities against the reason the module gave for excluding them, and to write this change, its tests and this description. I reviewed it and ran the tests and every linter myself before posting.)