Order the weighted admin lists by weight instead of creation order

Problem/Motivation

Six content entity types carry a weight base field that an operator can set on the entity form, and none of the admin lists that show them reads it. The lists come out in creation order.

Measured on the allotment list: three allotments with weights VIP 0, Guests 2, Schools 3 are listed VIP, Schools, Guests, which is their id order. The map picker shows the same three in weight order, because PinnedPlaceMapForm::allotments() runs its own query with ->sort('weight')->sort('label'). So the same tenant vocabulary is presented in two different orders depending on the screen.

The cause is inherited: a list builder that does not touch the query gets EntityListBuilder::getEntityListQuery(), which sorts on $this->entityType->getKey(static::SORT_KEY) with SORT_KEY = 'id'. Config entities do not have this problem, because ConfigEntityListBuilder::load() sorts through ConfigEntityBase::sort(), which is weight then label. Only the content entity lists are affected.

Affected: AllotmentListBuilder, PresetAllotmentListBuilder, PresetTariffListBuilder, ResourceTariffListBuilder, TariffClassListBuilder, TariffPresetListBuilder. The placement module is not affected: its screens build their own queries and already sort by weight.

Proposed resolution

One base list builder in yoyaku_ui that the six extend, overriding getEntityListQuery() to sort by weight, then by the type's label key when it declares one, then by id so the order is deterministic when both tie. yoyaku_preset_allotment declares no label key, which is why the second sort is conditional rather than hardcoded.

Overriding the SORT_KEY constant instead does not work: it is resolved through getKey(), and weight is not an entity key on these types, so it would resolve to FALSE and sort on nothing.

Weight then label is the order already chosen elsewhere in the engine, so this makes the admin lists agree with the picker rather than inventing an order.

Remaining tasks

• Add the shared base list builder and move the six onto it.
• Kernel coverage that a lower weight comes first and that equal weights fall back to the label, seen to fail against the current code.
• Check the pager still works, since the base class builds the query the pager attaches to.
• Documentation and French translation if any string changes.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. The new tests were confirmed to fail against the unpatched code and to pass with the change, on SQLite and on MySQL.)