Survey the OOB capability surface beyond power and console

Part of #1814

## Problem

The epic commits to out-of-band **power control and console access**. Service processors expose far
more than that, and KDIVE has no record of what is worth using. Without a survey, either the
capability surface gets designed from guesses, or an unbounded investigation blocks the spine.

Scope to investigate across Redfish, IPMI, and the HMC:

- **Sensor and health telemetry** — thermal, power draw, fan, PSU state. Could feed a
pre-allocation health gate or explain a mid-Run hang.
- **Boot-device override** — one-shot boot selection. Relevant to recovery when a freshly
installed kernel does not boot, though the epic's adopt-only stance keeps re-imaging out.
- **Virtual media** — mounting an ISO/image over the BMC. Deliberately adjacent to the "no OS
install" non-goal; the question is whether it has a *recovery* use, not a provisioning one.
- **Firmware inventory** — BIOS/UEFI/BMC versions as recorded Resource capabilities.
- **HMC-specific:** LPAR profile inspection, dump management (the HMC can manage platform dumps
independently of the guest's kdump), and partition state beyond on/off.
- **Crash triggers already known to be contested:** Redfish NMI and IPMI diagnostic interrupt.
#1808 found that both wrapped control planes refuse `interrupt` — confirm what the raw
interfaces expose.

## Evidence

- Epic #1814 requirement R4 scopes the OOB driver to power and console; the operator explicitly
asked to "investigate others that might exist".
- #1808 documents that MAAS's `hmc` driver declares `can_set_boot_order = False` and raises
`NotImplementedError` for reset, and that Beaker's `lpar` script rejects `interrupt` — evidence
that wrapped drivers hide capability the raw interface may have.
- #1775 and #1776 (under epic #1760) cover SoL and HMC vterm artifact capture, so console is
already well-trodden; this survey is about everything else.

## Expected outcome

- A written finding per capability: what each of Redfish/IPMI/HMC actually exposes, whether KDIVE
has a use for it, and what it would cost to wire.
- Follow-on issues filed for anything worth doing, sized to one PR each.
- Explicit "no" recorded for anything rejected, with the reason, so it is not re-surveyed.
- **No code.** This is a read-only investigation; it must not pre-empt the entry-4 port design.

Start with the capability evidence in #1808, including MAAS's hmc driver and Beaker's lpar script, then inspect the raw Redfish, IPMI, and HMC interfaces named in this issue. Record what each capability exposes, its KDIVE use and wiring cost, and finish with follow-on issues for worthwhile work plus explicit reasons for rejected capabilities.

Written by the indexing model from the issue text.