1. Why is this change necessary?

Stacked on #21822. Extensions can run their specs on the Administration's Jest harness (#21797) with their own Jest installation, as SwagCommercial does.

That only works while the extension's Jest has the Administration's major version: the harness's test environment and transformers come from the Administration's Jest. Once the Administration moves to the next Jest major, an extension still on the old one fails with errors deep inside Jest that do not point at the cause.

2. What does this change do, exactly?

• The Jest config factory compares the major of the Jest that loads the config with the Administration's and fails early with both versions, the jest@^N to install, and admin:test-extensions as the alternative
• The running Jest is read from the jest-config package in the module cache, the package that imports config files; the Jest bin path can name another Jest (import-local hand-over, programmatic runCLI)
• No check when no or several jest-config versions are loaded, e.g. when a script builds the config

3. Describe each step to reproduce the issue or behaviour.

In an extension with its own Jest of another major than the Administration's, composing the factory as described in #21797:

npx jest

This Jest config is loaded by Jest 30.2.0, but the Administration test harness in … is built for Jest 29.0.0. Install Jest 29 for your extension (`npm install --save-dev jest@^29`), or run the specs with `composer admin:test-extensions` …

With the same major, nothing changes.

4. Please link to the relevant issues (if any).

• relates feat(administration): introduce admin:test-extensions command #21822 (base)

5. Checklist

• I have written tests and verified that they fail without my change
• I have updated developer-facing release notes if this change is relevant for external developers:
  • Add a short entry to RELEASE_INFO-6.<current major line>.md in the upcoming version section for informational changes: what changed, who is affected, and how to adapt.
  • Add an entry to UPGRADE-6.<next major>.md for breaking changes and deprecations: what changed, who is affected, and how to adapt.
  • See the Documenting a Release Process for details.
• I have written or adjusted the documentation and agent skills according to my changes
• This change has comments for package types, values, functions, and non-obvious lines of code
• I have read the contribution requirements and fulfilled them