v0.7.1: walk the ladder once ever — persistent learned modes, rule pins, same-boot iPXE recovery

Answers the operational question 'can a machine try all three boot
binaries in one go?' The protocol can't carry three NBPs in one cycle
(one boot file per DHCP round, the Secure-Boot refusal happens after
handoff with no error report, and the broken-NIC case specifically needs
the firmware itself to load builtin-driver iPXE — GRUB's network rides
the same broken firmware stack). What we CAN do is make the walk a
once-per-machine-ever event and give operators a way to skip it:

- Learned driver modes persist (<work_dir>/driver_modes.json). A MAC
  that reaches the Shim rung, or confirms an iPXE handoff at Builtin,
  is pinned to disk: immune to the 30-min TTL, reloaded at startup.
  The file only carries exceptions — a healthy fleet never writes it.
  Corrupt file starts empty (standard crash-cache policy).
- Boot rules gain an optional driver_mode pin (auto/firmware/builtin/
  shim), consulted by the DHCP proxy BEFORE the escalation ladder:
  'this OUI is a Secure Boot rack -> serve shim immediately' = zero
  failed cycles. Mode-only rules coexist with target rules (a pin
  doesn't shadow a later target match). Editor column on Hosts tab.
- grub.cfg now tries to chainload all-drivers iPXE before showing the
  signed menu: with SB off the chainload succeeds and the client gets
  the full iPXE feature set back in the SAME boot (self-healing for
  mis-escalations, and the handoff then pins the working mode); with
  SB on, shim's verifier refuses it inline — no reboot — and the
  signed menu appears.

DhcpProxyServer now takes the escalation table + rules store from main
(persistence path comes from the configured work dir).

Validation: clippy clean, fmt clean, 299 workspace tests green (+9:
persistence round-trip across restart, Shim pin survives TTL, learned
Builtin survives TTL, corrupt-file recovery, default-mode-never-
persisted, rule-pin matching incl. unknown-mode tolerance and
pin/target coexistence, GRUB chainload-before-menu ordering, API
round-trip of the driver_mode field).

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

crates/openpxe/src/main.rs

@@ -184,6 +184,10 @@ async fn main() -> anyhow::Result<()> {
         "network info"
     );
 
+    // v0.7.1: boot rules are shared between the HTTP layer (target rules,
+    // webhook, the editor API) and the DHCP proxy (driver-mode pins).
+    let boot_rules = openpxe_core::BootRulesStore::load_or_default(&config.paths.work_dir);
+
     let state = AppState {
         iso_store: iso_store.clone(),
         clients: clients.clone(),
@@ -191,7 +195,7 @@ async fn main() -> anyhow::Result<()> {
         queue: queue.clone(),
         hosts: hosts.clone(),
         boot_log: boot_log.clone(),
-        boot_rules: openpxe_core::BootRulesStore::load_or_default(&config.paths.work_dir),
+        boot_rules: boot_rules.clone(),
         boot_tokens: openpxe_core::BootTokens::new(),
         branding: branding.clone(),
         pxe_bg_cache: openpxe_http_api::state::PxeBgCache::default(),
@@ -267,6 +271,10 @@ async fn main() -> anyhow::Result<()> {
                 public_base_url.clone(),
                 clients.clone(),
                 metrics.clone(),
+                // v0.7.1: learned driver modes persist next to the other
+                // state files, so a machine walks the ladder once *ever*.
+                openpxe_dhcp_proxy::DriverEscalation::load_or_default(&config.paths.work_dir),
+                boot_rules.clone(),
             );
             tokio::spawn(s.run())
         }