Boot from a declared integrated NIC while keeping its DPUs managed

[chet]

Today, booting a host from an integrated NIC requires declaring dpu_mode: no_dpu (or nic_mode), which makes site-explorer skip linking the host's DPUs as managed machines (no_dpu skips exploration entirely; nic_mode explores and issues set_nic_mode but never links them). For hosts whose DPU BMCs are cabled and explorable, we want to keep the DPUs managed and boot from the integrated NIC.

ExpectedHostNic.primary (the boot-interface axis) and dpu_mode (the DPU-management axis) are really separate concerns that today's single flag conflates. "Zero-DPU" / "DPU in NIC mode" really describes what the primary interface is, not that the host has no DPUs or that every DPU is unused.

Builds on #2657

#2657 makes the declared ExpectedHostNic.primary authoritative and stops configure_host_machine from claiming primary against a declaration. What's missing for the DPU-mode case is ownership: on a DpuMode host, a declared integrated NIC that DHCPs creates an anonymous (machine_id = NULL) row that no path adopts —

• host-NIC predictions are minted only in create_zero_dpu_machine (called once, machine_creator.rs), which doesn't run for DpuMode hosts;
• find_existing_machine (machine.rs) matches only already-owned MACs.

So pick_boot_interface (which reads owned interface rows) never sees the integrated NIC, even after the DPU is stopped from taking over.

The change

During DpuMode ingestion, also own the declared integrated NIC — e.g. mint a prediction for it carrying primary (reusing the prediction carrier added in #2657) so it's adopted and marked primary on its first DHCP, while the DPUs stay explored and linked but non-boot.

Open question: the integrated NIC's network segment type when the DPU normally serves the admin network (Admin vs HostInband vs other) — needs its own investigation of how an integrated boot/admin NIC gets its IP on a DPU host.

Conceptual: this nudges dpu_mode toward meaning "is the primary interface a DPU?", decoupled from "do we manage the DPUs." Decide whether to eventually express these as two independent fields.

Done when

• A host with cabled, explorable DPUs declared dpu_mode: dpu_mode that also declares an integrated NIC primary boots from that integrated NIC.
• The DPUs are still explored and linked as managed machines (not skipped).

Part of #2660.

[chet]

Implementation note discovered while building #2657:

The configure_host_machine change "must not promote a DPU interface when a different NIC is declared primary" cannot be done on its own. Demoting the DPU's host interface leaves a DPU-backed host with no primary admin interface, which reconcile_admin_addresses_for_host rejects during ingestion:

crates/api-db/src/machine_interface.rs:1689 — "Host ... has DPU-backed admin interfaces but no primary admin interface"

So this issue must own the declared integrated NIC as the replacement primary (admin) interface AND demote the DPU host interface together — they are coupled by that invariant. Demoting alone fails the host's ingestion outright (confirmed by an integration test).

Consequently #2657 leaves configure_host_machine unchanged (all DPU-mode declared-primary handling is #2668's). #2657 does ship the reusable foundation: a primary_interface column on predicted_machine_interfaces plus ExpectedMachineData::declared_primary_mac(), so #2668 can mint a prediction for the integrated NIC that promotes as primary while the DPU interface is demoted in the same pass.