fix(maven): send the official Maven CLI user agent to the maven2 registry; refresh npm wrapper lock for published 4.0.0 platform packages

[Mikola Lysenko (mikolalysenko)]

Problem

Maven Central is blocking / severely rate-limiting user agents containing socket. The CLI's only Maven Central-facing request — the maven2 fallback pom download in the maven vendor backend (acquire_upstream_pom → fetch_pom_bytes in crates/socket-patch-core/src/vendor/maven_repo.rs, default base https://repo1.maven.org/maven2) — sends the shared SocketPatchCLI/x.y.z UA and gets refused, so materializing a maven artifact whose upstream pom isn't in ~/.m2 fails.

Fix

maven2 registry requests now identify exactly as the official Maven CLI, matching the shape maven-resolver sends: Apache-Maven/<maven> (Java <jdk>; <os.name> <os.version>), pinned per-OS (Mac OS X / Windows / Linux variants) to fixed Maven/JDK/OS versions so the string stays deterministic with no runtime probing.

Scope: only the maven2 registry client changes UA — including private mirrors via SOCKET_MAVEN_REGISTRY, which serve real Apache-Maven/* traffic anyway. Socket API, telemetry, and self-update requests keep the honest SocketPatchCLI/x.y.z UA.

Tests

• maven_user_agent_is_the_maven_cli_shape: the constant leads with the Apache-Maven/ product token and never contains socket (the exact substring Central filters on).
• pom_fetch_sends_the_maven_cli_user_agent: wiremock only serves the pom when the request carries MAVEN_USER_AGENT on the wire, so a regression back to the CLI UA fails the fetch.

cargo test -p socket-patch-core --lib vendor::maven_repo → 33/33 green; cargo clippy -p socket-patch-core --all-targets clean.

🤖 Generated with Claude Code

---

Note

Low Risk
Narrow change to one HTTP client in the Maven vendor path; no auth, API, or lockfile behavior changes.

Overview
Maven Central was refusing or rate-limiting the fallback POM download used when vendoring Maven artifacts without a local ~/.m2 copy, because those HTTP requests used the shared SocketPatchCLI/x.y.z user agent (Central blocks strings containing socket).

fetch_pom_bytes in maven_repo.rs now sends a pinned, per-OS Apache-Maven/… user agent that matches the official Maven CLI shape instead of the Socket CLI UA. SOCKET_MAVEN_REGISTRY traffic is included; Socket API and other outbound calls are unchanged and still use the honest CLI UA.

Regression tests assert the UA is Maven-shaped, never contains socket, and is actually sent on the wire (wiremock). [Unreleased] changelog entry documents the fix.

^{Reviewed by Cursor Bugbot for commit b72c0dd. Configure here.}

[Mikola Lysenko (mikolalysenko)]

CI note: release-readiness was failing for a reason unrelated to the UA change — the committed npm/socket-patch/package-lock.json predates the npm 2FA approval, so the 4.0.0 @socketsecurity/socket-patch-* platform packages (unpublished at bump time) were silently omitted from the lock. Now that they're live, version-sync.sh re-adds their entries and the no-op check fails — on this PR and on main's next run alike. Second commit refreshes the lock with the published packages' integrity hashes; release-lint.sh --sync-only passes locally.