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 #22 and upstream fwmanager: Add the boot-progress walk over checkpoint windows OpenPRoT/openprot#395 (both closed): the old BootWalk/MonitorMap over BootMonitor.
• Upstream fwmanager: downstream update lifecycle tests with slot and boot-progress capabilities OpenPRoT/openprot#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]

Addressed the review, one commit per point:

• EvidenceReader for GpioBootMonitor: took the documentation route (1039660) — adapter crates can't implement EvidenceReader<G> because a board's signal vocabulary G isn't theirs to know; that boundary is the design working as intended. The trait docs now show the wiring shape (board impl owns the match, hardware binding made once at construction).
• Retry scheduling: WalkVerdict::Retry now carries deadline_millis of the re-armed window (716384e) — one scheduling rule for Waiting and Retry, no deadline arithmetic in the orchestrator.
• Migration note: added to the PR description (no CHANGELOG file in the repo yet); includes the before/after snippet, window → timeout + max_retries.
• Name uniqueness: validate now rejects duplicate checkpoint names per device at build time, with a reject-path test (da23a4b).
• max_retries = 0: pinned in the field docs — the one attempt is all the device gets (da23a4b).

[chrysh]

Round two addressed in 2134206:

• signal field doc: now says on the spot that it's a board-defined id resolved by the board's EvidenceReader, an id rather than a function so the table stays pure data, with a pointer to the type-level docs for the full trade-off.
• Board-local validation example: target/mock/devices.rs now demonstrates the pattern — a board-local const fn validate_signals (gpio line within the bank) running in the same const fence as the generic validate, and validate's docs point at it.
• Empty checkpoint list: already rejected — validate asserts !checkpoints.is_empty() ("device must declare at least one boot checkpoint") and rejects_an_empty_checkpoint_list covers the reject path. When passive devices arrive (slot-layout work, upstream fwmanager: Add per-device slot layout to the device-table schema OpenPRoT/openprot#394's CommitPolicy::None), that rule relaxes to "empty list only with CommitPolicy::None" — deliberate future change, not a gap today.

[chrysh]

@rusty1968 @FerralCoder @embediver — review requested (GitHub only let me formally request @leongross here since this is the 9elements staging fork). This replaces the BootMonitor/BootWalk approach from OpenPRoT#395; once it settles here it goes upstream as one PR.