fix: carry a network's fabric identity to every location it reaches

[scotwells]

What was wrong

A network present in two locations had a different VPC identifier in each, so its two halves were two VPCs on the fabric with different route targets and no connectivity between them. This is the split that deriving the identifier from a shared fabric identity exists to prevent.

Seen in the staging lab: taptest is 2 in us-central-1 and Aty7F5rG in us-east-1. The identity object exists only in us-central-1, and us-east-1 has the CRD registered with no objects and no Karmada work at all.

Why

Placement wrote one ClusterPropagationPolicy per location, each selecting identities by a cloud.datumapis.com/location-<location> label. An identity required in several locations carries several of those labels, so several policies select the same object. Karmada binds a resource to exactly one policy, so only one placement ever took effect and the others were silently ignored.

The controller was doing its part correctly — it computed both locations and stamped both labels, and applied both policies without error. The model was the problem: carrying one object to N clusters cannot be expressed as N single-location policies, because they compete for the object instead of composing.

It only shows up once a network reaches a second location, which is why it survived until now.

What changed

• Each identity gets one policy that names it (namespace + name) and lists every location it is required at, via a topology.datum.net/location In [...] placement. Naming the object makes contention impossible.
• collect removes that policy along with the identity, so a deleted network doesn't leave one behind.
• The per-location policies are swept once on startup. They're identified by shape — an owned policy whose selectors carry no resource name is selecting by label, which only the old form did — so nothing else is touched. They must go, because they keep competing for as long as they exist.

The location labels stay. Nothing selects on them now, but they remain the readable record of where an identity is needed.

Note for the rollout

This is necessary but not sufficient to align an existing split. A VPC that already has an identifier keeps it — deliberately, since renumbering renames a live VRF and moves routes under running traffic. Any VPC allocated before the fabric identity mechanism holds a legacy random value and needs a deliberate renumber; deleting the VPC object lets its owning NetworkContext rebuild it and re-derive.

Test plan

• An identity required in two locations produces one policy naming it and listing both
• No identity is selected by more than one policy
• A second network gets its own policy, rather than reusing one per location
• A legacy per-location policy is swept; a policy that names its identity is not
• Reverting the selector to the label form fails both new tests
• go build, go vet, full go test ./...