DomainOverrideConfigEntityConverter::applies() too broad -- breaks views_ui (and any other priority-10 entity:* converter)

Problem/Motivation

The domain_config_entity_ui submodule's DomainOverrideConfigEntityConverter param converter is registered with priority: 10 in domain_config_entity_ui.services.yml. It inherits applies() from core's AdminPathConfigEntityConverter, which returns TRUE for every entity:* parameter on an admin path, regardless of whether the entity type actually has domain-aware storage.

That ties on priority with views_ui's ViewUIConverter (also priority 10, views_ui.services.yml). When the Symfony route table is rebuilt, the param converter manager picks one of the two for the {view} parameter on routes such as entity.view.edit_form, entity.view.edit_display_form, etc. On sites where domain_config_entity_ui registers after views_ui in the container, the override converter wins. At runtime convert() sees that the View storage is plain ConfigEntityStorage (not DomainAwareConfigEntityStorageInterface) and defers to parent::convert(), which returns a bare Drupal\views\Entity\View with no ViewUI wrapping or tempstore lock metadata.

The View edit form then crashes with:

TypeError: Drupal\views_ui\Controller\ViewsUIController::edit():
  Argument #1 ($view) must be of type Drupal\views_ui\ViewUI,
  Drupal\views\Entity\View given
  in core/modules/views_ui/src/Controller/ViewsUIController.php line 211

Affects every admin path that goes through Views UI on any site that has domain_config_entity_ui enabled.

Steps to reproduce

1. Install domain, domain_extras, and enable domain_config_entity_ui on a Drupal 11 site.
2. Visit any view edit page (admin/structure/views/view/{any_view}).
3. Drupal returns the white-screen TypeError above.

Proposed resolution

Narrow DomainOverrideConfigEntityConverter::applies() to only the routes the converter actually handles, i.e. ones whose entity type has a DomainAwareConfigEntityStorageInterface storage. Routes for everything else fall through to the rest of the chain (notably ViewUIConverter for view edit routes), unchanged.

public function applies($definition, $name, Route $route) {
  if (!parent::applies($definition, $name, $route)) {
    return FALSE;
  }
  // Decline routes whose entity type is dynamic (entity:{entity_type})
  // since we cannot resolve the storage class here.
  $type_slug = substr($definition['type'], strlen('entity:'));
  if (str_starts_with($type_slug, '{')) {
    return FALSE;
  }
  if (!$this->entityTypeManager->hasDefinition($type_slug)) {
    return FALSE;
  }
  $entity_type = $this->entityTypeManager->getDefinition($type_slug);
  if (!$entity_type instanceof ConfigEntityTypeInterface) {
    return FALSE;
  }
  return $this->entityTypeManager->getStorage($type_slug)
    instanceof DomainAwareConfigEntityStorageInterface;
}

Verified locally: route inspection now shows converter: drupal.proxy_original_service.paramconverter.views_ui for entity.view.edit_form, and a programmatic run of the converter chain on view: text_xls_export returns a Drupal\views_ui\ViewUI as expected. View edit pages render again.

Remaining tasks

• Review the MR.
• Ship in 3.x.

Test coverage

The submodule's existing kernel test (DomainOverrideConfigEntityConverterTest) does not exercise applies(). The MR can either be left as-is or extended with an applies() test that asserts FALSE for an entity type with non-domain-aware storage; happy to do that as a follow-up.