DomainNegotiationContext is lost after mid-request container rebuild (module install/uninstall) -- per-domain config overrides stop applying to subsequent URL generation

Problem

When a form submission triggers ModuleInstaller::install() or ModuleInstaller::uninstall() mid-request, Drupal rebuilds the service container (DrupalKernel::updateModules() -> rebuildContainer()). The rebuild replaces every stateful service with a fresh instance -- including Drupal\domain\DomainNegotiationContext, which the DomainSubscriber had previously populated on KernelEvents::REQUEST. Nothing re-populates it after the rebuild.

Any code running after the rebuild in the same request that reads per-domain config through DomainConfigFactoryOverride then sees an empty context:

public function loadOverrides($names) {
  $domain_id = $this->domainNegotiationContext->getDomainId();
  if ($domain_id) {
    $storage = $this->getStorage($domain_id);
    return $storage->readMultiple($names);
  }
  return [];  // <-- hits this after rebuild, no override applied
}

Result: the ConfigFactory resolves language.negotiation (and any other domain-overridden config) from the base storage only. On sites that rely on the override for URL path prefixes (e.g. an override that sets the default language's prefixes.en to empty string), this is directly user-visible.

Reproduction

1. Multilingual site with language.negotiation:url.source = path_prefix.
2. Base config: prefixes.en = 'en'.
3. Domain override (via domain_config): on the English domain, prefixes.en = ''.
4. Normal navigation shows unprefixed English URLs (override active).
5. Go to /admin/modules, enable a module. Drupal's submit handler calls ModuleInstaller::install(['...']) then batch_process().
6. The batch redirect URL is built after the container rebuild. ConfigFactory->get('language.negotiation') reads base config without the override -> prefixes.en = 'en' -> redirect URL becomes /en/batch?id=....
7. On sites where /en/* is not a real reachable path (because English runs on its own domain or because the rewrite stack does not serve it), the redirect 404s.

Diagnostic trace

Every HTTP request shows the same ordering: DomainConfigFactoryOverride::loadOverrides('language.negotiation') fires once before DomainSubscriber::onKernelRequestDomain (middleware / early bootstrap lookups) with domain_id = NULL, then again after kernel.request with domain_id = <active-domain>. The two calls land in distinct ConfigFactory cache entries (keys include the override's getCacheSuffix(), so 'und' vs the active domain id), and most code paths hit the post-negotiation entry with the override applied.

On a module install/uninstall request, the submit handler runs updateKernel(), the DomainNegotiationContext instance is replaced by an empty one, and subsequent reads (e.g. batch_process()'s URL generation) see domain_id = NULL again. No override applies.

Proposed fix

Tag domain.negotiation_context with persist so DrupalKernel transfers the same DomainNegotiationContext instance from the old container to the new one across mid-request rebuilds.

services:
  domain.negotiation_context:
    class: Drupal\domain\DomainNegotiationContext
    tags:
      - { name: persist }

The context is pure state with no dependencies, so it is safe to share across the rebuild. Services that depend on it (DomainNegotiator, DomainConfigFactoryOverride) pick up the persisted instance through normal constructor injection in the rebuilt container. No re-negotiation work, no new hook plumbing.

This covers every mid-request kernel rebuild regardless of trigger, not just the two ModuleInstaller paths.

Environment

• Drupal core 11.3.x, PHP 8.3.
• domain 3.x-dev.
• domain_config enabled, with an override on language.negotiation.