Live proof: full BYO spine on a PowerVM LPAR via HMC

Part of #1814

## Problem

This is the epic's second blocking proof and the first time KDIVE runs against real POWER hardware.
Everything ppc64le to date has been a QEMU `pseries` guest under TCG emulation on an x86 host — the
arch traits, the ELF kernel contract, multiarch gdb, and fadump were all proven that way. An LPAR
exercises the parts emulation could not: real platform firmware, real HMC control, and
firmware-assisted dump driven by the platform rather than by QEMU.

fadump is the sharpest difference. Its support probe was written against a QEMU version floor,
which is meaningless here — #1829 replaces that with a real-firmware path, and this proof is where
that replacement is validated.

## Evidence

- Epic #1814 success criteria 2 and 3: a real vmcore from a PowerVM LPAR via HMC, including fadump,
retrieved and opened by drgn; plus a KGDB breakpoint and backtrace.
- `src/kdive/providers/shared/fadump_detect.py:17` — the QEMU floor this proof retires in practice.
- ADR-0349 (fadump), ADR-0353 (the three live tiers), ADR-0347 (cross-arch gdb) — all proven under
emulation only; this is their first real-hardware exercise.
- #1808 — establishes that no wrapped control plane can drive an LPAR's crash path, which is why
this proof runs against the direct HMC driver (#1822).
- #1792 records that an already-populated ppc64le PowerVM fleet exists with the `lpar` (IBM HMC)
power type working — relevant to sourcing the hardware, though this epic reaches the HMC directly
rather than through Beaker.
- Related prior work under epic #1760: #1782 (prove PowerVM FADUMP through the shared vmcore path)
and #1785. See #1814's overlap table.

## Expected outcome

- A full-spine proof on a real PowerVM LPAR: declare → `doctor` pre-flight → allocate → adopt →
install → boot → force-crash → **both kdump and fadump** → retrieve → drgn opens each core →
KGDB breakpoint and backtrace → release with baseline restore.
- The real-firmware fadump detection from #1829 confirmed against actual platform firmware, not
inferred.
- The cordon path proven, as on x86.
- A proof record committed alongside, naming which arms ran and on what hardware, in the style of
the existing `docs/design/*-proof-record-*.md` files.
- Every host tool the proof needed declared in the owning Ansible role in this PR; note that
`ppc64le` builds several tools from source (no prebuilt wheels), per the cross-platform guide.
- Independent of the x86 proof (#1814 entry 19) — different driver, arch, and hardware; neither
blocks the other.

Blocked by #1822
Blocked by #1828
Blocked by #1831
Blocked by #1830

Start with epic #1814 and the blocked dependencies #1822, #1828, #1831, and #1830, then review src/kdive/providers/shared/fadump_detect.py:17 and the existing docs/design/*-proof-record-*.md files. Run the full declared spine against a real PowerVM LPAR via the direct HMC driver, covering kdump, fadump, drgn, KGDB, cordon, and baseline restore. Done means a committed proof record and host tools declared in the owning Ansible role.

Written by the indexing model from the issue text.