Re-apply the user form display components the install profile overrides, and stop the tests depending on its front page

Problem/Motivation

The phpunit (next major) job on 4.x failed with eight failures across six classes. The job is allow_failure: true, so the pipeline still reported success. Nothing in this project caused it: the same failures appeared on two unrelated merge requests, one of which changes no test code at all. Core moved from dev-main 2ae8840, the last green run on 19 August, to dev-main eb6b6fd. There are two distinct causes.

The install profile overrides the user form display

domain_install() places field_domain_admin on the user.user.default form display, and domain_access does the same for field_domain_access and field_domain_access_all. Core hides configured fields by default, so that placement is what makes them appear at all.

An install profile is installed after the modules it ships with, because install_profile_modules() runs before install_install_profile(), and profile configuration overrides module configuration. The profile's own copy of that display therefore replaces the one domain saved, and core files the fields under "hidden". Nothing is logged, because both call sites bailed silently when the display was missing.

Measured on both lanes: on Drupal 11.4 the display carries account, field_domain_admin, language, timezone and user_picture; on Drupal 12 field_domain_admin is in hidden instead, while the field and its storage exist on both.

This is not test-only. Any site installing domain alongside an install profile loses these fields from the user form, on every core version, with nothing in the log. Core #3614825 only changed BrowserTestBase to install static::$modules through the profile path, which is what made CI walk into a defect that was already there.

The install profile's front page

Core #3590882 moved the Standard front page to /admin/welcome, which requires the "access administration pages" permission, so an anonymous request to a domain root answers 403. The same change dropped Olivero and made Claro the front end theme, and Claro places no main menu block. Core adapted its own StandardTestTrait to expect the 403 rather than making the page public, and published no change record for contrib.

DomainConfigHomepageTest failed for a related reason: core renamed the view serving /node from frontpage to promoted_content and ships the replacement disabled, so /node is a 404 and the assertion was comparing two identical missing pages.

Proposed resolution

• Use getFormDisplay() rather than loading the display and bailing when it is absent, so a profile that ships no display is handled instead of silently skipped.
• Re-apply the components from hook_modules_installed(), guarded by InstallerKernel::installationAttempted() so it runs only while the site is being installed and never overrides an admin who hid the field afterwards.
• Move the placement out of the procedural _domain_configure_field() into DomainEntityHooks::configureUserFormDisplay().
• Give the affected tests a published node as their front page through a createFrontPageNode() helper, place the main menu block in the test that asserts on it, and stop DomainConfigHomepageTest depending on the /node listing.

Remaining tasks

• Review and merge the merge request against 4.x.
• Backport to 3.x. The same defect exists on 3.0.x and 2.0.x, but those are maintenance branches, no one has reported it there, and the fix would need a deprecation shim on 3.0.x to stay backward compatible, so they are deliberately left alone.

User interface changes

None.

API changes

None.

Data model changes

None.

AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change on the merge request. The diagnosis was measured against the job artifacts on both lanes, and the result is green on the pipeline linked from the merge request.)