feat: out-of-band management (BMC) via Redfish, with IPMI as an optional fallback

Nobody has claimed this yet.

## Summary

Add out-of-band management for servers that have a BMC, so that power state,
hardware sensors and hardware event logs are reachable while the host OS is
down, hung or otherwise unreachable.

## Protocol choice: Redfish or IPMI

Recommendation: implement Redfish first, and keep IPMI over LAN as an optional
later fallback.

| Aspect | Redfish | IPMI 2.0 over LAN |
| --- | --- | --- |
| Transport | HTTPS + JSON (REST) | RMCP+ over UDP 623, binary |
| Client work in this repo | `dio`, no native code | no Dart implementation exists; needs a client in `crates/` behind FFI. `ipmitool` cannot be invoked on iOS/Android |
| Data model | self-describing: `Systems`, `Chassis`, `Thermal`/`Power`, `Storage`, `LogServices`, `Managers` | SDR / SEL / chassis commands; anything beyond that is vendor-specific `raw` commands |
| Auth | TLS, session token via `POST /redfish/v1/SessionService/Sessions` | RAKP handshake, with protocol-level weaknesses that firmware cannot fix (password hash retrieval for any known username, CVE-2013-4786; cipher suite 0 auth bypass) |
| Hardware coverage | most enterprise hardware from around 2016 on: iDRAC 8/9, iLO 5/6 (iLO 4 partial), Lenovo XCC, Supermicro X11+, ASRock Rack, Huawei iBMC, OpenBMC | everything above, plus older and entry-level BMCs that predate Redfish |
| Spec status | active DMTF spec | last revision is 2.0 rev 1.1 (2013); DMTF positions Redfish as the successor |
| Serial console | not covered; vendors expose HTML5 KVM instead | SOL, which maps onto the existing xterm |

Redfish covers power, inventory and sensors at a fraction of the implementation
cost here. IPMI stays relevant only for pre-Redfish hardware and for SOL.

## How it fits the current architecture

- A BMC is a separate endpoint from the host. It does not belong on the
`ServerConnectCredential` axis, which answers where the host's *status* comes
from. Model it like `WolCfg`: an optional side channel on `Spi`
(address, credential, certificate trust), independent of how the host itself
is reached.
- `ServerCapabilities` gains flags for what the BMC provides (power control,
hardware sensors, event log), so the UI keeps asking capabilities instead of
testing which protocol is configured.
- Reachability: a BMC usually sits on a management network that a phone cannot
route to. The monitor agent already relays SSH (`SshCredential.viaMonitor`);
relaying Redfish through the same agent would cover the same deployments.
- TLS: BMCs ship self-signed certificates. This needs the trust-on-first-use /
pinning treatment the app already applies to SSH host keys, and must not fall
back to disabling verification.
- Power state read out-of-band lets the server card show "powered off" rather
than a connection failure, and pairs with the existing WOL config, which
currently is the only out-of-band action in the app.

## Scope

Phase 1 — Redfish, read plus power:

- config UI: BMC address, username, password, certificate trust
- detection: `GET /redfish/v1/` (unauthenticated service root)
- `Systems/`: power state, model, serial, BIOS version, health rollup
- `Actions/ComputerSystem.Reset`: `On`, `GracefulShutdown`, `ForceOff`,
`ForceRestart`, `PowerCycle`, behind a confirmation dialog
- `Chassis//Thermal` and `/Power`: temperatures, fan speeds, PSU input
watts, feeding the existing status page (newer firmware also exposes
`ThermalSubsystem` / `PowerSubsystem`; both paths need handling)

Phase 2:

- `LogServices/SEL`: read entries, clear
- `Storage`: drive inventory, health, predictive failure
- boot device override, virtual media mount, indicator LED

Phase 3, optional:

- IPMI over LAN client in `crates/`, exposed through FFI, for hardware with no
Redfish
- SOL console routed into the existing terminal

## Open questions

- Whether IPMI is in scope at all, or Redfish only.
- Poll frequency. BMCs are slow, a `Thermal` fetch can take seconds. Separate
cycle from the host status poll, similar to how `SbStatusExt` is split out.
- Whether a BMC-only entry, with no OS-level access configured, should be a
first-class server in the list.

Start by tracing WolCfg, Spi, ServerConnectCredential, ServerCapabilities, SshCredential.viaMonitor, and SbStatusExt to understand configuration, capability reporting, and monitor-agent relaying. Review how the existing WOL configuration and SSH host-key trust are implemented before deciding how Redfish fits those paths. Done means an agreed Phase 1 design covering Redfish discovery, credentials and certificate trust, power actions, sensors, and polling; the issue's open questions still need resolution.

Written by the indexing model from the issue text.