feat(java): Gradle build, Maven Central packaging, bundled platform natives

[suchintan]

https://github.com/Skyvern-AI/rustwright-cloud/pull/99

[claude]

Summary

This PR is packaging/build infrastructure for the alpha Java binding (Gradle wrapper, Maven Central publishing via the vanniktech plugin, and bundled per-platform native libraries) — it doesn't touch src/lib.rs, the Python/Node API, or the CDP transport, so most of the usual Rustwright review checklist doesn't apply here. The new native-library resolution logic (NativeLibraryResolver) is sound and preserves the "explicit path is an exact pin" contract. A couple of things worth double-checking before merge.

🔴 Critical Issues (0)

None found.

🟡 Suggestions (3)

• Unverified Gradle task name: java/build.gradle.kts adds tasks.named("assemble") { dependsOn("plainJavadocJar", "sourcesJar") }. With mavenPublishing { configure(JavaLibrary(javadocJar = JavadocJar.Javadoc(), ...)) }, the vanniktech plugin's task for a plain java-library project is typically named javadocJar, not plainJavadocJar (the latter shows up in the Android/Kotlin-multiplatform variant configs, where "plain" distinguishes it from per-target doc jars). If that's right, ./gradlew build/assemble will fail at task-graph resolution. Worth confirming this was actually run locally (./gradlew build) before merge — there's no CI job in this repo that exercises the Java build, so this wouldn't be caught automatically.
• No CI coverage for java/: none of .github/workflows/*.yml build, test, or even ./gradlew tasks the new Gradle project (the contractSelfTest task added here has no runner either). Given this PR adds real release machinery (Maven Central publishing, native staging, checksum-pinned wrapper), it'd be worth at least a lightweight CI job that runs ./gradlew build and contractSelfTest on PRs touching java/, so regressions like the task-name issue above are caught mechanically instead of at release time.
• Repeated native-library extraction with no reuse: NativeLibraryResolver.extractBundled creates a brand-new temp directory and copies the native library out of the jar on every new Chromium() call, relying solely on deleteOnExit() for cleanup. In a long-running JVM that constructs many Chromium instances (e.g. a pooled test runner or server process), this accumulates one extracted copy of the native lib per instance until process exit. Consider memoizing the extracted path once per JVM/platform (e.g. a static, lazily-initialized field) instead of re-extracting each time.

📝 Minor / Style (2)

• The temp directory created in extractBundled doesn't set restrictive POSIX permissions explicitly (e.g. PosixFilePermissions.asFileAttribute(OWNER-only)); it relies on the process umask. Low severity since the library contains no secrets, but tightening this is cheap and is the more conventional pattern for extracted native libraries on shared/multi-user machines.
• Docs and version numbers look consistent and honest here: the README correctly states the Maven Central artifact is "not yet published," and 0.1.1 matches the version already used in node/package.json and Cargo.toml. No overclaiming, no scope creep — good.