Add the byo-host capture-coverage row and make a missing row detectable

Part of #1814

> **Re-scoped 2026-08-04 by #1840.** This issue was written against the M2 portability gate,
> which [ADR-0543](https://github.com/randomparity/kdive/blob/main/docs/adr/0543-retire-m2-portability-gate.md)
> retired. The baseline tag, the R9 allowlist entries and the CI-wiring decision it originally
> carried are gone — there is no gate to extend and no allowlist to add to. What survives is the
> capture-coverage drift guard, and the gap that makes it miss a new provider entirely.

## Problem

`tests/scripts/test_provider_capture_coverage.py` pins a per-provider `CAPTURE_COVERAGE` table
and imports the real `build_*_runtime` builders, so a provider whose advertised capture methods
disagree with its row fails `just test`. It is the only automated check that a provider's
advertised capture set is truthful, and epic #1814's success criterion 8 turns on it.

It has a hole. The guard asserts **two hardcoded keys** — `remote-libvirt` and `local-libvirt` —
against two named builders. Nothing enumerates the resolver's registered kinds, in either
direction. So registering `byo-host` (#1817) does **not** break the guard as this issue
originally claimed: the suite stays green and the new provider is simply invisible to it. A
missing row is undetectable, which is the failure mode worth closing.

## Evidence

- `tests/scripts/test_provider_capture_coverage.py` — `CAPTURE_COVERAGE`, a pinned
`dict[str, frozenset[str]]`, and `test_capture_coverage_matches_the_real_advertised_provider_sets`,
which asserts `CAPTURE_COVERAGE["remote-libvirt"]` and `["local-libvirt"]` against
`build_remote_runtime` and `build_local_runtime`. No iteration over registered kinds.
- ADR-0543 records the same gap in its Decision: "It enumerates nothing, so a newly registered
kind with no row stays green and undetected. Closing that is the registered-kinds completeness
assertion #1820 owns."
- Epic #1814 criterion 8, as restated after #1840: "The capture-coverage drift guard passes with
a `byo-host` row, and that row is enforced — a registered kind missing from the table fails
`just test` rather than passing silently."

## Expected outcome

- A `byo-host` row in `CAPTURE_COVERAGE` matching what the runtime actually advertises
(`kdump` on both arches, `fadump` on ppc64le; explicitly **not** `host_dump`, `console`, or
`gdbstub`), with the drift guard green.
- A **registered-kinds completeness assertion**: iterate the resolver's registered kinds and
require a `CAPTURE_COVERAGE` row for each, so a provider registered without a row fails rather
than passing silently. This is what turns the entry-17-after-entry-2 ordering from a convention
into an enforced one, and what makes criterion 8 checkable.
- Both mutation-verified — adding a kind with no row must redden the suite, and the restored tree
must be green.

## Out of scope

Re-introducing any form of portability diff measurement. ADR-0543 declined to build a
replacement: provider-specific logic reaching core is caught by review, and epic #1814's R9 now
declares the expected core touches for a reviewer to check against rather than measuring them.

Blocked by #1817

Start in tests/scripts/test_provider_capture_coverage.py, reading CAPTURE_COVERAGE and test_capture_coverage_matches_the_real_advertised_provider_sets, then trace the resolver's registered kinds and the build_*_runtime builders. Add the byo-host row and completeness check, verify the mutation case fails, and run just test with the restored tree.

Written by the indexing model from the issue text.