fwmanager: table-declared boot checkpoints replace BootMonitor

[chrysh]

Traits and schema only — the walker implementing them follows in a separate PR, so this one stays reviewable on the contract alone.

What

• BootMonitor is removed. A BootCheckpoint names its evidence as a board-defined signal id (signal: G, timeout, retry budget) — the schema names no signal kinds, and everything that is config is declared in the board device table (target/mock/devices.rs); config.rs only defines what that configuration has to look like.
• EvidenceReader<G> resolves a signal id to BootStatus — board wiring, typically one per managed device, exhaustive match, direct dispatch.
• BootStatus grows device-reported verdicts: FailedRetriable (consumes retry budget immediately instead of waiting out the window) and FailedFatal (ends the boot regardless of budget). Timeouts stay the observer's own judgment — hung devices report nothing; the reader tests pin this down with an MCTP-shaped mock where silence reads Booting forever.
• BootWatch/WalkVerdict is the erased seam the orchestrator polls: Waiting/Complete/Retry/Dead per device, free of device and error types.
• GpioBootMonitor keeps its behavior as a plain reader (inherent method, no trait).

Reading order

The first commit is the checkpoint-embedded-fn variant; the second defunctionalizes it into signal ids and records why (table stays pure data, borrows stay per-device, dispatch stays direct). The pair is kept deliberately as the design record — review the combined diff if you only want the endpoint. Commits three and four add the failure verdicts and the message-path reader tests.

Supersedes

• Boot progress walker 9elements/openprot#22 and fwmanager: Add the boot-progress walk over checkpoint windows #395 (both closed): the old BootWalk/MonitorMap over BootMonitor.
• fwmanager: downstream update lifecycle tests with slot and boot-progress capabilities #392's await_boot will need rework once this lands.

Test

bazel test //services/fwmanager/... (13 api tests), bazel build //target/mock/...; device-table validate runs in const context, so a bad table is a build error.

Migration (for integrators)

BootMonitor is replaced by EvidenceReader<G> + BootStatus; the checkpoint schema changed shape:

// before: one monitor per device, checkpoint carries a schema-level signal kind
BootCheckpoint { name: "boot-complete", signal: BootSignal::GpioBootComplete(12),
                 window: Duration::from_secs(90) }
impl BootMonitor for MyMonitor { fn boot_status(&self) -> Result<BootStatus, E> }

// after: signal id is the board's own enum; window -> timeout; new max_retries
BootCheckpoint { name: "boot-complete", signal: MySignal::Gpio(12),
                 timeout: Duration::from_secs(90), max_retries: 1 }
impl EvidenceReader<MySignal> for MyBmcReader {
    fn read(&mut self, signal: &MySignal) -> Result<BootStatus, E>
}

• max_retries: 0 = the single attempt is all the device gets.
• BootStatus::Failed split into FailedRetriable / FailedFatal (device-reported verdicts; timeouts remain the observer's judgment).
• Checkpoint names must be unique per device (build-time validate).
• WalkVerdict::Retry carries deadline_millis of the re-armed window — schedule against it exactly like Waiting.

[chrysh]

@rusty1968 three design notes worth discussing:

Timeouts stay per-checkpoint, and the SM never sees them. The device table declares a window per checkpoint (bl1 can get 200 ms while the service checkpoint gets 30 s); the boot walk consumes those windows and reports expiry as a failed attempt. I think Lou mentioned something about per checkpoint timeouts.

Open question 1 — FailureCause is richer than the SM's event vocabulary. The walk reports why an attempt died: TimedOut, DeviceRetriable, DeviceFatal (device-reported, e.g. a fault code meaning "re-running this image cannot change the verdict"). Today all three only become Event::Timeout(id), and every boot failure enters recovery — so DeviceFatal gets recovery-retried until max_retry exhausts anyway. Should the SM grow a fatal fast-path (straight to RecoveryFailed/isolation), or should we shrink the cause vocabulary until it's needed?

Open question 2 — where does ComponentAttrs get configured? The chain needs kind/failure_policy/depends_on per component, which is per-device board policy — but only the SM's tests supply it today, and after dropping CommitPolicy our table is pure name/reset/checkpoints. Does DeviceConfig grow those fields, or does a separate board-side table feed the chain?

Answers

Timeouts

The core has no sense of time. It has no clock and never measures how long anything takes. All the timing lives in the driver

The design doc explicitly says a boot-progress timeout is "Treated as a verification failure

When a boot watchdog fires the core just gets told "this attempt failed" — nothing more. The device table sets a time limit per checkpoint (bl1 might get 200 ms, the service checkpoint 30 s); the boot walk runs those timers and, if one runs out, reports it as a plain failed attempt. The core never sees the limit, how long it took, or that a timer was even involved. This lines up with Lou's point on per-checkpoint timeouts: the limits live in the device table, one per checkpoint, and never become something the core knows about.

Open Question 1

The guiding principle: the orchestrator core should decide on its own evidence, not on device feedback. A DeviceFatal diagnose is the device classifying itself; acting on it means letting an unverifiable self-report drive control flow. The core's retry loop is precisely its own device-independent check — re-quiesce, re-verify at rest, try max_retry times, then decide. I'd rather the terminal decision rest on that than on the device's word, since how trustworthy "fatal" is depends entirely on the device.

And a fast-path doesn't actually buy safety, only latency. Both ways a device can misclassify already converge to the same fail-closed state:

says "fatal" when retriable → we isolate/lock something recoverable (availability loss, still fail-closed);
says "retriable"/times out when actually fatal → we retry, exhaust max_retry, gate/lock anyway.
So honoring "fatal" only reaches a state we'd reach regardless, just sooner — at the cost of a trust assumption I don't want to make.