Reach the Code Genome Project from the release and bump workflows

[timtebeek]

• Follow-up to Allow resolving dependencies from the Code Genome Project #1183. That PR added the codegenome profile to pom.xml and exported CODEGENOME_USERNAME/CODEGENOME_TOKEN on ci.yml's build step — but only that step. Everywhere else the profile silently stays inactive, because it activates on the presence of env.CODEGENOME_USERNAME.

What that costs today

• bump-snapshots.yml runs versions:update-properties against Maven Central and ossrh-snapshots only. A rewrite.version published solely to CGP is invisible to it, and the failure mode is silence: the weekly job just stops finding newer snapshots. publish.yml runs the same goal twice and has the same blind spot.
• publish.yml's release:prepare/release:perform rebuilds from a fresh checkout on a fresh runner. Any CGP-only dependency fails outright there.
• ci.yml's publish-snapshots step is unaffected in practice — it runs after build on the same runner, so ~/.m2 is already warm — but it inherits the same wiring gap.

None of this bites while CGP publishing is additive to Sonatype (RewriteCgpPublishPlugin registers the S3 bucket "so publish uploads there too"). It bites when ossrh snapshot publishing stops.

The --global-settings bit

setup-java writes a single server per call and overwrites settings.xml on each one, so the two servers can't come from one file. Steps that pass --settings=$GITHUB_WORKSPACE/settings.xml ignore ~/.m2/settings.xml entirely, so a second setup-java call alone wouldn't reach them — worse, exporting the env var without credentials would activate the profile and send unauthenticated requests at CGP.

So those steps now pass the codegenome file as --global-settings as well. Maven merges global and user settings, unioning servers with distinct ids. Verified locally:

$ ./mvnw --global-settings=global.xml --settings=user.xml help:effective-settings
      <id>ossrh</id>
      <id>codegenome</id>

release:perform forks a Maven process, and the release plugin propagates the outer build's effective settings to it, so the fork inherits the merged servers; the profile re-activates in the fork from the inherited env.

Notes

• bump-snapshots.yml deploys nothing, so its ossrh server was unused — that call is repurposed for codegenome rather than adding a third.
• The rollback step is left alone: release:rollback reverts poms and drops the tag, and resolves nothing from CGP.
• Fork PRs receive no secrets, so the profile stays inactive there, unchanged from Allow resolving dependencies from the Code Genome Project #1183.
• Repository order is already correct — the effective pom with the profile active resolves codegenome → ossrh-snapshots → central, matching what RewriteDependencyRepositoriesPluginTest.codegenomeResolvedBeforeSnapshotsAndMavenCentral asserts on the Gradle side. Out of scope here, but unlike the Gradle plugin the pom can't group-scope CGP to org.openrewrite/io.moderne, so every third-party artifact is queried against it first.