Bazel consolidation phase 2: visibility policy, Gazelle enforcement, nested-module guard

Description

Phase 2 of #448. Establish visibility policy, root-run Gazelle enforcement, the
nested-module guard, and the extended affected-target CI.

This is the highest-risk part of the migration and it is structural. Removing a
workspace root changes what its labels mean: //:__subpackages__ currently scopes
to one service and would expand to the whole repository under the root.

Measured on main 1f8ea711: 156 root-relative //:__subpackages__ declarations
outside vendored code, 647 //visibility:public occurrences, and one
package_group definition. The expressed API surface is very broad and nearly
uniform, so it must be inventoried before it is restricted.

That single package_group arrived with the notary import (#447), which replaced
two root-relative __subpackages__ visibility entries with a named group and
also added a Java-scoped nested-module guard to the Bazel workflow. Both are the
pattern this phase generalizes, and both appeared without this plan, which is
evidence the need is felt independently.

The guard this phase builds is not a single allowlist. It has the three
mechanisms defined in #449: exact vendored-path exclusions, a migration and
retirement ledger that must shrink monotonically, and permanent service
exceptions carrying the exception contract. Only the third category survives the
final phase.

Definition of Done

• Default-private service packages with explicitly exported APIs.
• Allowed cross-layer dependency groups defined as package_groups.
• A query or aspect check for forbidden cross-service edges.
• Root-run Gazelle regeneration with an idempotence check.
• Nested-module guard generalized beyond Java, implementing all three mechanisms
  rather than one allowlist.

Resources

• #448, #449
• #447 (first package_group, Java-scoped guard)