Wire the EC2 Bazel remote cache for the standalone Java modules

Context

Java services are moving to standalone Bazel modules: nv-boot-parent and nvcf_java_rules live outside the root module, and each Java service (starting with cloud-tasks) is its own module that bazel_deps them and builds individually.

Today cloud-tasks builds inside the root module: .github/workflows/bazel.yml includes src/control-plane-services/cloud-tasks/ in ROOT_GLOBS, so it inherits the root job's --config=remote and gets EC2 Buildbarn cache hits. Once it becomes its own module it drops out of ROOT_GLOBS and loses cache coverage unless the cache is wired explicitly, the same way the other service modules get it.

Current gap

• rules/java/.bazelrc has no remote-cache config.
• There is no src/control-plane-services/cloud-tasks/.bazelrc and no dedicated matrix row for it.
• Service modules do not set --config=remote; the workflow injects --remote_cache / --tls_certificate / --remote_header=authorization=Bearer for them. The Java modules must opt into that path (or set an equivalent config) or their CI builds go cache-cold.

What to wire

1. Matrix row(s) in .github/workflows/bazel.yml for the standalone Java module(s), is_root=false, and remove cloud-tasks/ from ROOT_GLOBS when it becomes its own module.
2. Confirm the non-root cache-injection block covers the Java build (endpoint BAZEL_REMOTE_CACHE_ENDPOINT, BAZEL_REMOTE_CACHE_CA, token BAZEL_REMOTE_CACHE_TOKEN).
3. Release path: nvcf-internal tools/ci/build_bazel_release_manifest.sh already probes the CI-variable-driven EC2 endpoint; verify it works for a Java type: bazel build.
4. Verify: a cold vs warm CI run shows remote cache hits for the Java module; no Java module builds cache-cold.

Acceptance

Standalone Java module CI builds show EC2 Buildbarn cache hits and no module is silently cache-cold after the root-module split.

Relates to #343 (cloud-tasks import) and the standalone Java module work.

Start with .github/workflows/bazel.yml, comparing the non-root matrix and cache-injection block, then inspect rules/java/.bazelrc and the cloud-tasks module path. Check nvcf-internal tools/ci/build_bazel_release_manifest.sh for a Java type:bazel build. Done means standalone Java CI shows EC2 Buildbarn cache hits in cold and warm runs, with no Java module cache-cold.