feat(vpc): cozyplane variant of the VPC application - #4508

What this PR does

Stacked on #3149. The cozyplane networking variant skips the kube-ovn/multus-backed virtualprivatecloud application, which left the VirtualPrivateCloud catalog kind absent on cozyplane clusters. This PR adds an alternative flavor of the same catalog kind, backed by cozyplane's sdn.cozystack.io API, and wires it in as a second variant of the existing delivery:

• packages/apps/vpc-cozyplane — a chart that creates a namespaced VPC (address ranges may overlap between VPCs; isolation is by overlay), the owner-namespace VPCBinding (attachment is default-deny even for the owner), one VPCPeering half per declared peer (bidirectional declaration, same UX as the kubevirt flavor's peers), and an optional VPCGateway (gateway.enabled / nat / ingressLoadBalancer / loadBalancerClass).
• virtualprivatecloud-rd now selects which ApplicationDefinition it installs by a variant value: both flavors register the same kind with the same release prefix, but each definition must point at its own variant's ExternalArtifact. The cozyplane definition is generated by the same hack/update-crd.sh flow; the script now honors VARIANT/OUT from the environment instead of always reading variants[0] of the PackageSource.
• cozystack.virtualprivatecloud-application gains a cozyplane variant whose ordering edge is cozystack.cozyplane-apiserver (the group is aggregated-only) instead of cozystack.multus, and the iaas bundle selects the flavor by bundles.system.networkingVariant, replacing the previous skip.

Covered by helm-unittest suites in all three places: chart rendering (binding always present, gateway/peering shapes, loadBalancerClass absent when empty), rd variant selection (exactly one definition, correct chartRef, unknown variant fails the render), and platform wiring (bundle flavor selection, dependency edges with no multus edge on cozyplane).

Not in scope, deliberately: cross-namespace VPCBindings (sharing a VPC with another tenant's namespace), reserved NAT identities (addressClaimName waits on the address substrate), and e2e — real-cluster validation of the whole cozyplane stack is tracked on #3149.

VM attachment (added 2026-10-08). vm-instance now joins a VM to a cozyplane VPC: when the cluster serves sdn.cozystack.io (API discovery, the same gate as the Kube-OVN IP pinning), the chart stamps sdn.cozystack.io/vpc: virtualprivatecloud-<networks[0].name> on the virt-launcher pod and renders no multus networks and no secondary interfaces — the VM keeps its single pod interface. The values contract is unchanged for consumers: networks: [{name: <VPC catalog name>}], the name without the virtualprivatecloud- prefix, same convention as peers[].vpcName; at most one entry (more fails the render by name, since a cozyplane pod joins exactly one VPC). The Cilium-variant multus path is untouched and both branches are unit-tested.

Still to verify on a live stand, not by rendering: which KubeVirt interface binding the default interface needs on cozyplane (the template uses bridge: {}; masquerade may be required), whether the guest acquires the VPC address over DHCP, and whether kubevirt.io/allow-pod-bridge-network-live-migration still applies — the CNI stamps sdn.cozystack.io/vpc-ip/-mac on the launcher pod to check against.

Screenshots

Not a UI change.

Downstream repositories

The trigger map fires for cozystack/website (a new package under packages/apps/ needs an entry in the website Makefile's app lists, and the variant recomposition touches the variants page) and arguably for terraform-provider-cozystack (the VirtualPrivateCloud spec differs per flavor, so the hand-maintained schema will not match cozyplane clusters). Both follow-ups are deferred while this stack is draft — filing them against an unmerged experimental variant would be noise; they should be opened when #3149 leaves draft. Boxes left unticked so a human decides.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

feat(vpc): the cozyplane networking variant now serves the VirtualPrivateCloud application, backed by sdn.cozystack.io — namespaced VPCs with peering and an optional north-south gateway