Status, application, tenant and workflow option lists ignore the weight that orders them

Problem/Motivation

The five example statuses ship with a lifecycle weight: Under review 0, Changes requested 1, Being processed 2, Processed 3, Rejected 4. Every select that offers them lists them alphabetically instead, so the requester's status filter reads Being processed, Changes requested, Processed, Rejected, Under review.

The cause is TenantScopedRepositoryBase::getAvailableIdsInTenant(), written for #3624939 and now shared by statuses and applications: it asks the config entity query for ->sort('label') alone. The weight both entity types declare to order them among their neighbors is read by the admin list and by nothing a person picks from.

The same gap is open at more doors:

• InstanceFilterForm::getTenantOptions() builds its own tenant select with natcasesort(), a private copy of TenantContext::getTenantOptions() that drops the tenant weight #3624939 made every other tenant select honor.
• InstanceFilterForm::getWorkflowOptions() sorts workflows by label, although the Workflows list is a draggable list whose weight is exactly this order.
• WorkflowFilter::getValueOptions(), which #3624942 exposed on the personal task lists, lists workflows in storage order, that is by machine name.
• The unscoped branches of InstanceStatus and ApplicationFilter use loadMultiple() as it comes, also by machine name.
• The subprocess node's Child process select and the webform handler's Start workflow select list workflows by machine name too.

Proposed resolution

Order every one of these lists the way the entity type itself sorts, weight then label, which is ConfigEntityBase::sort() and what every config entity list builder uses.

• The repository base loads the tenant's terms and sorts them with the entity class's sort(); the ids come from that sorted list, so both methods agree.
• InstanceFilterForm asks TenantContext::getTenantOptions() and deletes its copy, and sorts workflows the same way.
• WorkflowFilter, InstanceStatus, ApplicationFilter, SubprocessTask and OrchestraInteractionHandler sort what they offer the same way.

With every weight at the default 0 the lists are ordered by label, naturally and case-insensitively, as the admin lists already are.

The views Workflow filter also gains an Order of the workflows setting (option_order): As arranged on the Workflows list, the default, or By label, for a site with too many workflows to arrange by hand.

Remaining tasks

None beyond the change and its tests.

API changes

None in shape. The repository interfaces documented their answers as ordered by label; they now say weight, then label.

AI-Generated: Yes (Claude Code found this in a pre-release audit of the module, drafted this issue summary, and wrote the change and its tests on the merge request.)