ci: pin Maven Central publishing to Maven 3.9

[GregHolmes]

Summary

• add the official Maven Wrapper 3.3.4 scripts (mvnw, mvnw.cmd) pinned to Maven 3.9.16, the version that last published successfully from CI
• publish release artifacts through the wrapper instead of runner-provided Maven
• prevent Maven 3.10 local metadata from entering Central bundles
• allow a manual workflow run to republish the current POM version after a failed Central deployment
• document the Central release flow, the Maven 3.10 pin, and the retry workflow in AGENTS.md

Validation

• ./mvnw --version
• ./mvnw package -DskipTests -P release -Dgpg.skip=true
• ./mvnw --settings ../maven-test-settings.xml deploy -DskipTests -P release -Dgpg.skip=true -DskipPublishing=true
• ./gradlew spotlessCheck test compileExamples

The non-uploading Central bundle contains only versioned artifacts under com/deepgram/deepgram-java-sdk/0.11.1/, including its POM. Re-verified with Maven 3.9.16 via the retry layout (PR-head mvnw against a v0.11.1 checkout).

[dg-coreylweathers]

Requesting changes: one blocking fix, two lines.

What this PR does: The 0.11.1 release run this morning tagged v0.11.1 but Maven Central rejected the upload, so 0.11.1 is not installable (the POM returns 404). This pins publishing to Maven 3.9.11 through the Maven Wrapper and adds a manual trigger to re-run the publish.

Blocking — [B1] mvnw and .mvn/ are not in .fernignore. Every other build file is frozen there (lines 102-108), and Fern deletes files it does not generate. After the next regen, ./mvnw deploy fails with "No such file" and the release after it breaks the same way this one did. Fix: add after Makefile in .fernignore:

mvnw
.mvn/

and add both to the permanently frozen build-config bullet in AGENTS.md.

Should-fix — [S1] Manual re-run publishes main HEAD, not the release tag. If a PR merges after a failed publish, a dispatch uploads that unreleased code to Central under the old version, and Central versions are immutable. Safe today (main == v0.11.1). Suggested guard in the publish job (with fetch-depth: 0 on checkout):

- name: Verify manual publish targets the release tag
  if: github.event_name == 'workflow_dispatch'
  run: |
    version=$(jq -r '."."' .github/.release-please-manifest.json)
    if [ "$(git rev-parse HEAD)" != "$(git rev-parse "v${version}^{commit}")" ]; then
      echo "HEAD is not v${version}; dispatch from the tag or from main before new merges." >&2
      exit 1
    fi

Nits

• [N1] .mvn/wrapper/maven-wrapper.properties: pin the download with distributionSha256Sum=0d7125e8c91097b36edb990ea5934e6c68b4440eef4ea96510a0f6815e7eeadb (SHA-512 of the zip matches Central's published checksum).
• [N2] AGENTS.md:51 still says CI publishes via mvn deploy -P release; now ./mvnw deploy -P release.

What I checked

• Diagnosis: reproduced in Docker. With Maven 3.10.0 the Central bundle carries maven-metadata-local.xml and _remote.repositories; through ./mvnw (3.9.11) it holds only the 20 versioned files under 0.11.1/.
• mvnw is byte-identical to Apache's maven-wrapper-distribution 3.3.2 only-script; the 3.9.11 distribution URL resolves.
• Re-running 0.11.1 is safe now: no commits on main since v0.11.1, and Central never accepted the version.
• CI: compile and unit tests on Java 11/17/21 and spotless all green.

[dg-coreylweathers]

Approved.

What this PR does: Java SDK 0.11.1 never reached Maven Central because GitHub's build machines switched to Maven 3.10, which adds a local file (maven-metadata-local.xml) to the upload, and Central rejects the whole upload because of it. This PR publishes through a checked-in Maven Wrapper pinned to Maven 3.9 and adds a manual workflow that re-publishes an existing release tag.

What I checked:

• Is the diagnosis right? Yes. runner-images ubuntu24/20261004.327 moved Maven 3.9.16 → 3.10.0, after 0.11.0 published. Building v0.11.1 with Maven 3.10.0 in Docker put maven-metadata-local.xml in the bundle.
• Does the fix work? Yes. The PR-head mvnw, run against a v0.11.1 checkout the way the retry workflow does it, downloaded Maven 3.9.16 fresh, passed the checksum check, exited 0, and produced a bundle with only the 20 versioned 0.11.1 files.
• Can the retry workflow publish the wrong commit? No. It requires tag == v and HEAD == the tag's commit.

Changes I pushed in 61a1fea, from my review:

• Retitled fix: → ci: so release-please doesn't propose an empty 0.11.2 with a CI line in the changelog.
• Replaced mvnw with Apache's published wrapper 3.3.4 script, byte for byte. The previous copy said 3.3.2 but had a modified checksum block. Added the matching mvnw.cmd for Windows and froze it in .fernignore.
• Pinned Maven 3.9.16, the version that last published successfully from CI. Its SHA-256 matches the zip, whose SHA-512 matches Apache's published value.
• Added a "Releasing to Maven Central" section to AGENTS.md: why the pin exists, not to bump it to 3.10, and how to run the retry workflow.

After merge: dispatch "Retry Maven Central Publish" with v0.11.1 and confirm Central lists 0.11.1.