[TASK] CI: Maven wrapper bootstraps from Maven Central uncached — a 429 kills the whole run

Description

Every Maven job in CI bootstraps Maven itself by downloading a ~9 MB zip directly from Maven Central,
uncached and without retry, as its very first action. When Central rate-limits the runner, the job dies
before executing anything — and because the test matrix runs fail-fast, one such job cancels the
entire run and trips the automatic DO NOT MERGE: title prefix.

Observed on run 31221514474 (PR #36966). The
Postman Tests - Page job failed 392 ms into its build step:

Building Maven with args ... verify -pl :dotcms-postman -Dpostman.test.skip=false -Dpostman.collections=page
Exception in thread "main" java.io.IOException: Server returned HTTP response code: 429 for URL:
  https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.2/apache-maven-3.9.2-bin.zip
    at org.apache.maven.wrapper.DefaultDownloader.downloadInternal(DefaultDownloader.java:95)
    at org.apache.maven.wrapper.Installer.createDist(Installer.java:84)
    at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:73)
##[error]Process completed with exit code 1.

That single failure cancelled 23 other jobs (The strategy configuration was canceled because "test.test-matrix._240_ubuntu-latest_-Xm_13" failed) and failed Finalize / Final Status.

Why it is not just a transient

Two gaps make a routine 429 fatal:

1. The wrapper bootstraps from Maven Central, not from our own Artifactory.
.mvn/wrapper/maven-wrapper.properties:

distributionUrl=https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.2/apache-maven-3.9.2-bin.zip
wrapperUrl=https://repo.maven.apache.org/maven2/org/apache/maven/wrapper/maven-wrapper/3.2.0/maven-wrapper-3.2.0.jar

This is inconsistent with the rest of the build — pom.xml routes every other artifact through
https://repo.dotcms.com/artifactory/libs-release. Only the bootstrap of Maven itself reaches a third
party.

2. Nothing caches the distribution. Searching .github/ for wrapper/dists, maven-wrapper or
distributionUrl returns zero matches, and the job log confirms it: the job restores caches for SDKMAN,
the JDK, the Node binary and the pnpm store, but re-downloads the Maven zip every time.

Central rate-limits by source IP, and GitHub-hosted runners share IP ranges across many customers, so
hitting a 429 is a matter of timing rather than of anything we do. The blast radius is every Maven job in
every workflow, and it presents as a test failure until you read the log.

Acceptance Criteria

• distributionUrl and wrapperUrl in .mvn/wrapper/maven-wrapper.properties resolve through
  repo.dotcms.com/artifactory instead of repo.maven.apache.org
• ~/.m2/wrapper/dists is cached in .github/actions/core-cicd/maven-job/action.yml, keyed on a
  hash of .mvn/wrapper/maven-wrapper.properties
• A clean runner with a cold cache still bootstraps successfully (verify on a PR run, not only locally)
• Local developer builds are unaffected — ./mvnw still works for anyone outside the VPN/network, or
  the fallback is documented if it does not

Priority

None

Additional Context

Searched open and closed issues for maven wrapper 429 rate limit and repo.maven.apache.org 429 —
nothing tracked this, so it is likely being absorbed as "flaky CI" and re-run away each time.

Optional hardening beyond the two fixes above: the wrapper download has no retry. Even once it points at
Artifactory, wrapping the bootstrap in a retry would turn a transient blip into a delay rather than a red
build.

Full diagnosis, including the rejected hypotheses (PR code defect, flaky Postman test) and the evidence
for each: .claude/diagnostics/run-31221514474/DIAGNOSIS.md.

One tooling note for whoever picks this up: the dot-cicd-diagnose skill's evidence.py reported
pnpm version mismatch as the failure for this run. That is a false positive — it matched the ::error::
text inside the guard's shell source, while the check actually passed (pnpm version in sync: 10.17.1).
The extractor should match emitted output, not script bodies.

Start with .mvn/wrapper/maven-wrapper.properties and .github/actions/core-cicd/maven-job/action.yml, then inspect how the Maven jobs restore caches and bootstrap ./mvnw. Done means the wrapper URLs use repo.dotcms.com/artifactory, ~/.m2/wrapper/dists is cached using the properties hash, a cold-cache PR run succeeds, and local builds remain usable outside the network.