Reconcile Provisional Primary-DPU Selections from Scout

[chet]

Parent epic: #5008

This connects Scout PCI candidate evaluation to the shared atomic alignment operation at safe lifecycle boundaries, then reuses the existing desired boot-interface and BootConfiguring flow to converge Redfish configuration. API Core records the corrected intent and enqueues the stable host ID; machine-controller remains responsible for lifecycle transitions, Redfish work, and reboots.

What this involves

• Evaluate only selections marked RedfishChassisId or RedfishSerialNumber.
• Suppress automatic replacement for ExpectedMachine, Operator, RedfishUefiPci, ScoutReportPci, and LegacyUnknown.
• Use fresh authenticated Scout data after stable-ID resolution, or a discovery boundary that proves the report was persisted.
• Allow settlement during initial HostInit or later Ready with no instance; never mutate an assigned or instance-bearing host.
• When Scout selects the current target, record ScoutReportPci without desired/network generation changes or a reboot.
• When Scout selects a different target, atomically align primary/network/desired/source state, commit, and enqueue.
• Let the existing pending-generation checks enter BootConfiguring::Prepare; API Core must not write controller state directly or force the machine backward.
• At the beginning of Prepare, wait until every expected DPU has observed the new host network-configuration version before any Redfish, lockdown, or reboot work.
• Reuse existing vendor jobs, recovery, reboot, lockdown restoration, and exact desired-generation verification.

Acceptance criteria

• A complete same-target candidate settles without network work or reboot.
• A complete different-target candidate aligns state atomically and enters existing convergence.
• Incomplete or ambiguous evidence retains the provisional choice and reports why settlement could not run.
• Allocation and correction serialize on the machine lock; an assigned host receives no side effects.
• BootConfiguring::Prepare performs no Redfish or lockdown action before DPU network versions synchronize.
• Controller restart during the sync wait and host restart during Redfish convergence resume safely.
• Rebooted Scout registration keeps the existing no-op control behavior and does not restart the full discovery lifecycle.
• Repeated reports cannot flip a settled choice or create a reboot loop.
• An end-to-end two-DPU test covers early serial/chassis order disagreeing with Scout PCI order.
• Real supported GB200 vendor/firmware reports validate chassis-to-PCI correlation, Scout path parsing, DHCP/Admin-address behavior, and rollout gating before enablement.
• No new top-level or serialized controller state is introduced.

Blocked by the chassis-ordering, Scout-evaluation, and atomic-alignment tasks. Part of #5008.