Java framework changes rebuild dependent services but release none of them

[balajinvda]

Summary

A change to the shared Java framework src/libraries/java/nv-boot-parent
rebuilds every dependent Java service in CI but releases none of them.

.github/workflows/bazel.yml already carries the reverse-dependency edge: it
reads the per-component bazel-java-ci.json descriptors, sets
java_framework_changed=true when a changed path sits under a
component_kind: java-framework component, and schedules every
component_kind: java-service row. So the dependents are built and tested.

Release automation has no matching edge. tools/ci/github-release auto runs
npx semantic-release per registered subproject with
semantic-release-monorepo, which scopes commits to the service directory. A
commit touching only src/libraries/java/nv-boot-parent matches no registered
service path, so cloud-tasks, notary, and api-keys each report
"no relevant changes" and cut nothing. nv-boot-parent is not itself a
registered subproject in tools/ci/github-release-subprojects.json, so nothing
is released for the framework either.

Impact

A framework change can alter the behaviour of cloud-tasks, notary, and
api-keys, pass CI, and ship no new version of any of them. The rebuilt
artifacts exist only inside the CI job. Consumers pinned to the last released
version never receive the change, and there is no released artifact that
corresponds to the current framework state.

Expected

A framework change that leaves a dependent service with nothing to release
should still cut a release for that service, sourced from the same descriptor
graph bazel.yml uses rather than a second hardcoded list.