Integrate IPAM and compute networking interface

[scotwells]

Problem

Today, NSO has hardcoded IP address ranges for a fixed set of locations. This means:

• New locations can't come online without a code change
• There's no conflict detection — two workloads could receive the same IP
• Compute has to know about NSO-internal resources (NetworkBinding, SubnetClaim) to attach an instance to a network, creating a tight coupling that is hard to evolve independently

What we're building

Real IPAM integration

Replace the hardcoded allocation logic with dynamic allocation backed by the platform IPAM service. When a user enables networking in a project, the project receives a unique private IPv6 address range. Subnets and instance addresses are allocated on demand with full conflict detection.

The addressing strategy is covered in #163.

Clean compute/networking interface

Introduce two new resources: NetworkInterfaceClaim and NetworkInterface. Compute creates a claim expressing intent to attach an instance to a network at a location. NSO fulfills it by allocating an IP and creating a NetworkInterface. Infra providers (GCP, Unikraft) watch only NetworkInterface — they no longer need to walk internal networking resources to find an address.

This decouples compute from NSO internals and gives providers a single, stable resource with everything they need to configure a NIC.

What this enables

• New locations come online automatically — no code changes required
• Conflict-free IP allocation with a full audit trail of what's assigned to what
• Compute and networking can evolve independently
• IP reservation and reuse via retain policies (modelled on Kubernetes PV/PVC)
• Foundation for public IPv6 support

Dependencies

• milo-os/ipam#25 — new IPPool / IPClaim / IPAllocation API required before NSO integration work can begin

Design

Full technical design: enhancements/ipam-integration.md