Publish the Java binary atomically across JVMs (#329)

[css521]

Fixes #329.

BinaryResolver previously copied directly to the shared cache path and only set the executable bit afterwards. Parallel JVMs could therefore resolve and execute a partial or non-executable file, while an interrupted copy left a truncated cache entry that later runs trusted permanently.

This serializes extraction across JVMs with a file lock, copies to an owner-specific staging file in the cache directory, validates its length and permissions, and publishes it with an atomic rename. Cache hits are accepted only when they are regular, complete, and executable. Lock acquisition is bounded and also handles overlapping locks from independent classloaders in one JVM.

Verified locally:

• BinaryResolverExtractionTest passes with real child JVM contention at javaParallel=4
• The focused suite covers cold-cache contention, stale entries, interrupted extraction, fail-closed publication, and concurrent classloaders
• ./gradlew --offline build -x test --rerun-tasks
• git diff --check

The synthetic executable used by the regression suite is a POSIX shell payload, so that suite explicitly skips on Windows; Windows publication is not claimed as locally verified.