ci(bazel): evaluate shared Java prebuild

[kristinapathak]

Description

Evaluate a merge-queue Java prebuild that warms the remote cache before service test fan-out. It should reduce duplicate NV Boot compilation without increasing wall time.

Definition of Done

• Compare current and prebuild runs for an NV Boot change.
• Record wall time, Bazel actions or cache-hit rate, and runner minutes.
• Adopt it only if it reduces wall time and duplicate work. Otherwise retain the current fan-out.

Resources (optional)

• .github/workflows/bazel.yml

[balajinvda]

Looked into this and the in-monorepo case turns out to already be safe, so I closed #697 rather than land the gate.

Java services depend on nv-boot-parent by source label, e.g. api-keys has //src/libraries/java/nv-boot-parent/nv-boot-starter-core:nv_boot_starter_core in its deps. nv-boot-parent has no MODULE.bazel of its own and there is no com.nvidia.boot Maven coordinate anywhere in the Bazel files, so it is not a published artifact from CI's point of view. Bazel therefore rebuilds the framework from current source as part of every service build, and a service cannot pick up a stale version regardless of job order.

Ordering the jobs would still buy fail-fast (one clear framework failure instead of five confusing service ones) and cache warming on main pushes. On pull requests cache upload is off, so services would wait on the framework and get no reuse. That seemed like the wrong trade to make for a correctness problem that does not exist.

Where a stale version does look possible is outside this repo: nvct-service on GitLab consumes the monorepo via bazel_dep, so it resolves nv-boot-parent at whatever revision it is pinned to rather than from local source. If that is the case you had in mind, the fix belongs at the pin/publish boundary and I am happy to pick it up. Could you confirm which one you were seeing?