Install profile's PSR-4 namespace never registered — 500 error on Standard profile front page

Generated with the help of an LLM.

Problem/Motivation

Installing Drupal core (main / 12.0-dev) with the Standard profile and
visiting the site's front page (/) afterwards returns an
uncaught PHP exception and a 500 error, for every anonymous visitor,
permanently.

Root cause: DrupalKernel::setExtensionData() determines
which discovered profiles are eligible for PSR-4 namespace registration by
intersecting them against $this->moduleList (built from
the module: config key only). Since
core.extension.schema.yml tracks the active install profile
in its own, separate profile: key, the active profile is
never a member of $this->moduleList, so its namespace
(e.g. Drupal\standard\) is never registered with the class
loader. This is permanent, not just an install-time glitch, because it is
baked into the compiled container.namespaces parameter.

The Standard profile's front page route
(standard.welcome, path /admin/welcome) requires
\Drupal\standard\Controller\WelcomeController::access as a
_custom_access callback. Because the class can never be
autoloaded, ClassResolver::getInstanceFromDefinition() throws
\InvalidArgumentException, which
CustomAccessCheck::access() re-throws as an uncaught
\BadMethodCallException, surfacing as an HTTP 500 to the
visitor.

Steps to reproduce

1. On an unmodified checkout of Drupal core (branch main),
   run

   composer install --no-dev --no-interaction
     --optimize-autoloader

   from the project's own
   composer.lock.

2. Run the web installer (core/install.php). Choose any
   database backend (tested with SQLite) and the Standard
   install profile. Complete the "Configure site" step with any values.
3. Wait for installation to finish; the installer redirects to the
   site's front page.
4. Observe: "The website encountered an unexpected error. Try again
   later." The PHP error log shows:

   Uncaught PHP Exception BadMethodCallException: "The
   "\Drupal\standard\Controller\WelcomeController::access" method is not
   callable as a _custom_access callback in route "/admin/welcome"" at
   core/lib/Drupal/Core/Access/CustomAccessCheck.php line 60

5. Independent confirmation, isolated from HTTP/routing entirely:
   

   $ php -r 'require "autoload.php";
   var_dump(class_exists("\Drupal\standard\Controller\WelcomeController"));'
   bool(false)

The condition is permanent and 100% reproducible on every request —
the response carries X-Drupal-Dynamic-Cache: UNCACHEABLE (500),
confirming Drupal's own caching layer does not treat it as transient.

The Standard profile is the installer's default-recommended option, so
this affects the default new-site experience. The Demo: Umami profile
ships its own namespaced hook classes (Drupal\demo_umami\Hook\...)
that are affected the same way, though without a hard crash, since its
front page does not depend on them directly — meaning this also causes a
silent loss of hook functionality for any install profile shipping its
own module code.

Proposed resolution

DrupalKernel::setExtensionData() should also consider the
active install profile (e.g. via $this->getInstallProfile())
when building the set of profiles eligible for namespace/class-loader
registration, not rely on $this->moduleList alone, since
that list no longer contains the active profile under the current
core.extension schema.

Remaining tasks

Patch needs to be written and reviewed by core maintainers. A
regression test performing a full Standard-profile install followed by an
anonymous request to the configured front page (asserting a 200 response)
is recommended to prevent recurrence.

User interface changes

None. This is a bug fix with no intended UI change; the only visible
effect of fixing it is that the front page loads correctly after a
Standard-profile install instead of returning a 500 error.

Introduced terminology

None.

API changes

None expected. The fix is internal to
DrupalKernel::setExtensionData()'s extension-discovery logic
and should not change any public API signature.

Data model changes

None.

Release notes snippet

Fixed a bug where the active install profile's own PHP classes were
never registered for autoloading, causing sites installed with the
Standard profile to show an uncaught exception and a 500 error on the
front page.