Reserve DPU Loopback Addresses

[chet]

DPU loopbacks do not use the ExpectedInterface allocation path. An ExpectedInterface describes an interface identified by a MAC that obtains an address through DHCP or a preallocated machine_interface row. A DPU loopback has no MAC or DHCP request. NICo allocates it from the lo-ip or optional lo-ip-v6 resource pool, stores it in the DPU machine's ManagedHostNetworkConfig, and returns it to the pool when the DPU is permanently deleted.

Today NICo automatically allocates any missing loopback while it creates or completes the DPU network configuration. That keeps the address stable for that machine record, but it does not let IPAM select an address before ingestion. Force deletion of a DPU without prior decommissioning returns the reservation even though the hardware may still have the previous loopback configured.

Managed host decommissioning from #4370 is the supported way to scrub the DPU before permanent deletion. This epic does not replace that workflow or add live loopback readdressing. It adds deterministic loopback reservations for sites that need the same address selected by IPAM whenever NICo ingests a particular DPU.

What This Needs To Accomplish

• Let an ExpectedMachine describe optional IPv4 and IPv6 loopback reservations for each expected DPU.
• Associate each configured reservation with the intended DPU on hosts with more than one DPU. The matching serial number must be available before the DPU MachineId exists, and the association must not depend on list order.
• Require configured reservations to come from lo-ip or lo-ip-v6 ranges marked auto_assign = false, so automatic allocation cannot select them before ingestion.
• Assign the configured value when NICo creates or completes the DPU network configuration, then keep the existing ManagedHostNetworkConfig and resource pool allocation as the stored state.
• Keep the current automatic lo-ip and lo-ip-v6 allocation when no reservation is configured.
• Reject a configured value that is not an available explicit value in the corresponding pool, including a value allocated to another DPU.
• Define what happens when ExpectedMachine is edited or removed, when an operator force deletes the DPU, and when the same hardware is ingested again.
• Support IPv4 and IPv6 independently.
• Ensure older Core, REST, and admin clients do not erase DPU reservations when they read and then rewrite an ExpectedMachine.

Technical Details

ExpectedMachine.fallback_dpu_serial_numbers can identify multiple DPUs before their MachineId values exist, but the flat serial number list cannot attach a loopback reservation to one DPU. The new configuration needs an optional structured declaration keyed by the DPU serial number, while the existing field and its behavior remain supported. A structure such as ExpectedDpu could contain the serial number and optional loopback_ip and loopback_ip_v6 values without treating the loopback as another physical interface address.

The existing resource pool allocator already accepts a requested value. Explicit reservations should use rows with auto_assign = false; existing automatic ranges keep their current behavior. ExpectedMachine validation must reject duplicate declarations and values that cannot be requested from the corresponding pool. Once the DPU exists, the resource pool allocation uses its MachineId, and ManagedHostNetworkConfig.loopback_ip and loopback_ip_v6 remain the stored fields.

db::machine::create, Site Explorer, direct machine discovery, and IPv6 startup or resource pool growth reconciliation can all populate missing loopback state. They need one shared reservation resolution and allocation operation so serial matching, requested value handling, and lifecycle behavior remain consistent.

Configuration changes should not readdress an active DPU. A different address should take effect only after the supported decommission or delete and ingestion flow. Live correction of an existing DPU loopback remains separate in #2096.

The vpc-dpu-lo pool has a different lifecycle, with one allocation for each DPU and VPC, and is outside this epic.

Delivery

This is an Epic because the work should remain reviewable as focused changes:

• Define the structured expected DPU reservation contract and compatibility behavior.
• Integrate reservations with Core allocation, deletion, later ingestion, and reconciliation tests.
• Expose the new ExpectedMachine fields through gRPC, the admin CLI, and REST without changing existing field behavior.
• Document configuration and lifecycle behavior in a separate docs PR.

Compatibility

All new configuration must be optional. Sites that do not configure DPU loopback reservations continue using automatic resource pool allocation without changing their existing configuration.

Follow-up from #3491.