Ensure the boot config through one shared mechanism across reboot-wait states

[chet]

Summary

The state machine establishes a host's boot config once, early -- but several later stages reboot the host, and each has grown its own way of noticing that the config drifted across a reboot and putting it back: the boot-configuration ladder, host boot repair in DPU reprovision, and most recently machine validation (#3365). The mechanics are already shared (set_host_boot_order, the lockdown choreography, is_bios_setup); what is duplicated per stage is the noticing, the routing, and the resume.

Consolidate all of it under a single mechanism for ensuring the boot config.

What this involves

• A top-level EnsureBootConfig state with a resume continuation: it checks lockdown and unlocks if needed (tolerating vendors that report but can't set it), drives the boot-order flow to put the config back, re-locks per the expected-machine policy, and resumes the interrupted state.
• Machine validation's ensure states (feat: ensure a correct boot config during machine validation #3369) and DPU reprovision's host boot repair migrate into it -- one implementation, with compatibility for records still in the old states.
• Detection moves to the shared reboot-wait (trigger_reboot_if_needed): when reboots stop helping and the boot config reads drifted, any waiting stage transitions to EnsureBootConfig -- current and future reboot sites get this without per-stage code. Flows where a config change is expected (cleanup, secure erase, BIOS updates) opt out.
• The establish path (PollingBiosSetup, SetBootOrder in HostInit) stays as is -- first-time application is a different lifecycle phase and already correct.
• Coverage for the vendor-specific legs (Supermicro post-unlock reboot, NotSupported handling, lockdown-disabled profiles) as table-driven tests.

One PR: this is a single consolidation, and it reads best as one atomic change.

Part of #870.