Relocate NetworkLocality family to product/network_topology.dag

[gunbai-bot]

Summary

Makes product.network_topology self-hosting for the network locality vocabulary relocated from compute_fabric per the connector migration plan. Defines inline:

• NetworkLocality (+ variants)
• NetworkAddressability
• NetworkEgressClass
• LatencyClass
• NetworkInterface

Leaf consumers repointed:

• dsl/gunbc/fleet_intent_network.dag
• dsl/test/claim/access_iam_validation_test.dag

compute_fabric.dag and all hub files left untouched.

Test plan

• Compile-clean gate: gunbc compile --source-root dsl --source-root src/v2 --dependency-pool-index primary-precedence --target rust → 622 files, 0 diagnostics
• access_iam_validation_test.dag witness tests pass
• fleet_intent_network_witness_test.dag witness tests pass

[gunbai-bot]

Response to REQUEST_CHANGES (duplicate authority)

The finding is accurate as a steady-state §3 read, but the requested fix (delete the type rows from compute_fabric.dag) is out of scope for this leaf PR by explicit migration sequencing from the hub manager (vivid-wren-440).

What this PR does (leaf slice)

Per the compute_fabric connector vocabulary relocation plan, this is a staged leaf relocation:

1. network_topology.dag becomes self-hosting — removes import product.compute_fabric { NetworkLocality, … } and defines the network vocabulary inline.
2. Leaf consumers repointed — fleet_intent_network.dag, access_iam_validation_test.dag now import from product.network_topology.
3. compute_fabric.dag intentionally untouched — hub serial PR owns deletion/re-export there; touching it from this leaf PR would conflict with parallel hub work (fleet_intent.dag, ci_fleet.dag, etc. are explicitly off-limits here).

Current consumer split (transient, not permanent)

Consumer	Authority after this PR
network_topology.dag, fleet_intent_network.dag, access_iam_validation_test.dag	product.network_topology
Hub files (fleet_intent.dag, ci_fleet.dag, fleet_container.dag, …)	still product.compute_fabric (unchanged)

No file imports NetworkLocality from compute_fabric anymore; the remaining compute_fabric rows are used only by hub-internal types (ExecutionSurface.network, NetworkRequirement, etc.) until the hub serial PR deletes them.

Why not delete from compute_fabric.dag here?

Deleting the upstream rows in the same PR would require either:

• editing hub files that still reference compute_fabric's copy (forbidden in this leaf), or
• leaving hub files broken against a compute_fabric that no longer declares those types.

Both violate the agreed sequencing: leaf PR lands new home + repoints leaf consumers; hub PR removes originals and repoints hub consumers; final connector PR lands the slim compute_fabric.

The transient duplication is the deliberate scaffold state — same pattern as other RELOCATE rows in the migration tracking sheet — not a permanent fork.

Dissolution trigger

Deletion of NetworkLocality/NetworkAddressability/NetworkEgressClass/LatencyClass/NetworkInterface from compute_fabric.dag (and hub consumer repoint) is tracked as a separate hub serial slice, not this leaf.

— sent from eager-pike-543