Add the BYO install and boot/readiness planes

Part of #1814

## Problem

An adopted host already runs an OS with its own bootloader. Installing an agent's kernel therefore
means editing that bootloader — `grubby` on x86 EFI, grub2-PReP/petitboot on PowerVM — rather than
handing a kernel to a hypervisor at domain-define time as every current provider does.

Confirming the install worked is the second half of the problem. A BYO host's console is
out-of-band, so readiness cannot be a console marker the worker greps locally; the boot-id change
is the signal that the machine actually came back on the new kernel.

## Evidence

- `src/kdive/providers/ports/lifecycle.py:178` — `Installer.install`, and `:194` — `Booter.boot`.
- `src/kdive/providers/remote_libvirt/lifecycle/install.py:187` — the in-target install precedent
(ADR-0082): the **target** pulls the kernel bundle from a presigned GET URL; the worker never
pushes it. `:255` is the matching `boot`, and `:381` is `_read_boot_id`, the console-less
readiness signal. Install and boot live in one module there because readiness is the second half
of a successful install.
- `src/kdive/providers/shared/ssh_connect_retry.py` — the shared SSH retry helper.
- `src/kdive/domain/platform/arch_traits.py:85` — `arch_traits()`; whether it splits for metal is
decided in #1815 (open question 4), and this entry consumes that decision.
- ADR-0343 — the arch-keyed kernel-artifact contract (bzImage for x86_64, ELF `vmlinux` for
ppc64le) already exists and applies unchanged.

## Expected outcome

- `Installer.install` writes the kernel into the running OS's bootloader over SSH, arch-keyed, and
sets the crashkernel reservation the capture entry depends on.
- The kernel is pulled in-target via presigned GET, consistent with ADR-0082 — no artifact is
pushed from the worker.
- `Booter.boot` confirms readiness by boot-id change, with OOB console evidence surfaced on the
failure path rather than a bare timeout.
- Deadlines state all five parts of the limit contract; a real machine's POST time is much longer
than a VM's, so the windows are not inherited from the libvirt providers unexamined.
- An install that leaves the host unbootable is a recorded, recoverable state — it must not strand
the System with no path forward.

Blocked by #1823

Start by reading src/kdive/providers/remote_libvirt/lifecycle/install.py at the cited install, boot, and _read_boot_id sections, then inspect src/kdive/providers/ports/lifecycle.py and the shared SSH retry helper. Check arch_traits() and ADR-0343, while accounting for the decisions in #1815 and the blocking work in #1823. Done means BYO install, boot-id readiness, failure evidence, deadlines, and recoverable failure state meet the listed outcome.

Written by the indexing model from the issue text.