Release: generate the extension load list instead of hardcoding it (Phase 2.5)

[PurHur]

Next Phase 2.5 increment, after the declarations in #24387.

What changes

Runtime::loadCoreModules() carried 76 hardcoded new ext\X\Module calls, so adding an
extension meant editing a core file — the opposite of the plan's "a new extension is a directory,
not a core edit". The list now lives in generated lib/ExtensionRegistry.php, and Runtime
iterates it.

Order is unchanged, and that is checked three ways

This is the safety argument for the whole refactor, so it is not left to inspection:

1. the generator copies the order verbatim from the hardcoded list;
2. verified identical at generation time — 76 == 76, same sequence;
3. test/unit/ExtensionRegistryOrderTest.php freezes the first 25 entries against a literal list, so
   a regeneration or hand edit that reorders anything fails and names the position.

Ordering here is load-bearing (libxml → dom → xsl) and only partly declared via
Module::getExtensionDependencies(), so deriving a fresh order from dependencies remains a
separate step that has to be proven equivalent first.

Two constraints worth knowing about

Literal new expressions, not dynamic instantiation. The AOT compiler resolves
new \PHPCompiler\ext\spl\Module() statically. A new $className loop would leave every module
unreferenced and uncompiled — the registry would load nothing into an AOT binary.

--check mode. php script/generate-extension-registry.php --check fails when the committed
file is out of date, so the generated file cannot drift from its generator.

A finding from writing the test

20 modules deliberately report getExtensionName() === 'standard' — zip, intl, gd,
bcmath, bz2, ftp, msgpack and others expose their functions as part of ext/standard in
php-src terms.

So the reported extension name is not unique and cannot identify a registry entry. The ext/
directory can. The test and both tools now key on the directory, and anything that later selects
extensions per build will need the same distinction — it would otherwise silently conflate 20
modules into one.

Tooling that would have gone blind

script/check-extension-dependencies.php and script/extension-inventory.php both parsed
Runtime::loadCoreModules(). After this change that method has no list to parse — the inventory
reported 0 loaded and all 76 "not loaded", which is exactly the kind of quiet breakage that makes
a check useless. Both now read the registry, with a fallback to Runtime for pre-registry trees.

Verified after the fix: 76 loaded, no phantoms, no unloaded directories — identical to before.

Gate

Branch vs a clean master checkout, sequential, both cold, each sweep allowed to complete
before diffing:

	branch	master
cold aot-smoke	8/8	8/8
VM --repeat 2	110/110, exit 0	110/110, exit 0
AOT --repeat 3	13 failing	13 failing

regressions (branch-only): NONE
fixed (master-only)      : NONE

Plus ExtensionRegistryOrderTest (2 tests, 231 assertions), check-extension-dependencies ok,
generate-extension-registry --check ok.

Still not selectable

Every module loads, isDefaultEnabled() is true everywhere, and the registry is the default set.
Filtering on it is the next step — this change only moves the list somewhere it can be generated and
checked.