Issue #3589233: Narrow DomainOverrideConfigEntityConverter::applies() to domain-aware storage

Summary

The domain_config_entity_ui submodule's DomainOverrideConfigEntityConverter inherits applies() from core's AdminPathConfigEntityConverter, which returns TRUE for every entity:* parameter on an admin path. Combined with priority: 10, this ties with views_ui's ViewUIConverter (also priority 10). At route-rebuild time the manager picks one of the two for routes such as entity.view.edit_form; on sites where this submodule registers second, it wins and convert() defers to parent::convert() for non-domain-aware storage, returning a bare View instead of the ViewUI the controller expects.

The result is a hard crash on every Views UI edit page once domain_config_entity_ui is enabled:

TypeError: ViewsUIController::edit(): Argument #1 ($view) must be of type
Drupal\views_ui\ViewUI, Drupal\views\Entity\View given

Fix

Override applies() to only claim routes whose entity type has a DomainAwareConfigEntityStorageInterface storage. Routes for all other entity types fall through to the rest of the converter chain (notably ViewUIConverter for the View edit forms).

Verification

Verified on a Drupal 11.3.9 site running domain 3.x + domain_extras 3.x with domain_config_entity_ui enabled:

• Before: route inspection on entity.view.edit_form shows converter: domain_config_entity_ui.paramconverter.configentity_admin. View edit page crashes.
• After: route inspection shows converter: drupal.proxy_original_service.paramconverter.views_ui. Programmatic run of the converter chain on view: text_xls_export returns a Drupal\views_ui\ViewUI. View edit pages render correctly.

Test plan

• Pipeline passes.
• Existing DomainOverrideConfigEntityConverterTest still green.
• Manual: edit a view on a site with both modules enabled.

Follow-up

Could extend DomainOverrideConfigEntityConverterTest with an applies() test that asserts FALSE for an entity type whose storage is not domain-aware. Happy to add as a separate MR if you'd prefer.