fwmanager: Drop InReset; document the BootStatus subset contract

InReset is orchestrator state, not something a monitor can observe —
a device held in reset reads exactly like one still booting, so the
variant could never be reported. Remove it from BootStatus.

Document on boot_status() that any given backend may only ever produce
a subset of BootStatus depending on the signals it can access (a single
ready pin yields only Booting/Booted); this is a capability difference
between backends, and consumers must still handle the full set.

Addresses review feedback on PR #368.

Assisted-by: Claude:claude-fable-5
Signed-off-by: Christina Quast <christina.quast@9elements.com>

services/fwmanager/api/src/boot_monitor.rs

diff --git a/services/fwmanager/api/src/boot_monitor.rs b/services/fwmanager/api/src/boot_monitor.rs
index 931970e..9695688 100644
--- a/services/fwmanager/api/src/boot_monitor.rs
+++ b/services/fwmanager/api/src/boot_monitor.rs
@@ -12,8 +12,6 @@
 /// orchestrator's timeout, not by this enum.
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 pub enum BootStatus {
-    /// Held in reset by the orchestrator; not yet released.
-    InReset,
     /// Released, but boot completion not yet observed.
     Booting,
     /// Boot completion observed.
@@ -50,6 +48,13 @@
 
     /// Returns the current liveness of the device.
     ///
+    /// Any given monitor may only ever produce a *subset* of [`BootStatus`],
+    /// depending on the signals it can access: a single ready pin yields only
+    /// `Booting`/`Booted`, while a fault-channel backend can also report
+    /// `Failed`. This is a capability difference between backends, not an
+    /// incomplete implementation. Consumers must still handle the full set —
+    /// they cannot know statically which backend they hold.
+    ///
     /// # Errors
     ///
     /// Returns an error if the underlying liveness signal cannot be read.