Add BYO crash capture and retrieve: kdump on both arches, fadump on POWER

Part of #1814

## Problem

Capturing the vmcore is the point of the whole epic — everything upstream exists to produce this
artifact. On a BYO host the crashed kernel writes its core to the machine's own local storage
(the capture kernel is a minimal initramfs and cannot be assumed to reach S3), and the worker
retrieves it on the next normal boot.

There is no `host_dump` fallback here. On a VM, a hypervisor can dump guest RAM when kdump fails;
on metal there is no such vantage. **kdump and fadump are the only capture methods**, which makes
their reliability load-bearing rather than merely nice.

fadump also has a concrete defect to fix: the current support probe keys on a **QEMU version
floor**, which is meaningless on a real LPAR where the platform firmware provides
`ibm,configure-kernel-dump` unconditionally.

## Evidence

- `src/kdive/domain/capture.py:12` — `CaptureMethod.KDUMP`, and `:16` `FADUMP`: "Firmware-assisted
dump (POWER pseries, ADR-0349): a memory-preserving reboot the platform firmware drives, reusing
the kdump userspace and retrieve path."
- `src/kdive/providers/shared/fadump_detect.py:17` — `PSERIES_FADUMP_QEMU_FLOOR = (10, 2)`, derived
from "the version of the same ppc64le emulator `guest_arches` already discovered". A real LPAR
has no QEMU version to read, so this probe cannot work as written.
- `src/kdive/providers/remote_libvirt/retrieve/kdump_capture.py` — the two-phase capture/retrieve
precedent (ADR-0084), with `retriever.py` and `common.py` alongside.
- `src/kdive/providers/remote_libvirt/lifecycle/install.py:302` — `_await_kdump_armed`, the
reservation-confirmation precedent.
- Related prior work under epic #1760: #1781 (baseline kdump vmcores on both architectures) and
#1782 (PowerVM FADUMP through the shared vmcore path). See #1814's overlap table.

## Expected outcome

- kdump armed and its crashkernel reservation confirmed before a Run is allowed to crash, on both
arches — an unarmed host must fail early, not after the crash destroys the evidence.
- Vmcore retrieved to the object store and referenced by row, following the two-phase remote
pattern.
- fadump support on ppc64le, with the QEMU-version probe **replaced** by a real-firmware detection
path per #1815's decision (device-tree property, RTAS call, or recorded operator assertion). The
existing QEMU path must keep working for the emulated tiers — this is a generalization, not a
swap.
- `ProviderSupport.capture_methods` advertises exactly `{kdump}` on x86 and `{kdump, fadump}` on
ppc64le, matching the #1820 coverage table.
- An incomplete core is reported as such with a remediation, reusing the existing
`kdump_core_incomplete` vocabulary rather than a new string.

Blocked by #1825
Blocked by #1827

Start with src/kdive/domain/capture.py and the existing two-phase precedent in src/kdive/providers/remote_libvirt/retrieve/kdump_capture.py, retriever.py, and common.py. Read fadump_detect.py and lifecycle/install.py:_await_kdump_armed, then review #1815, #1820, and the related #1781/#1782 work. Done means armed kdump is confirmed before a run, vmcores are retrieved and referenced, firmware and emulated FADUMP detection both work, advertised methods match the coverage table, and incomplete cores reuse kdump_core_incomplete.

Written by the indexing model from the issue text.