Build-failure remediation tells operators to chmod 0644 the kernels provisioning keeps at 0640

## Problem

When a guest-image build fails because the libguestfs appliance cannot read the host kernel, kdive
emits a remediation string telling the operator to run `sudo chmod 0644 /boot/vmlinuz-*`.

`0644` is the exact mode the provisioning role forbids. `boot_kernels.yml` carries the reasoning and
the prohibition in terms: *"no path here may reach 0644."* The role applies `0640 root:kvm` so the
kernels stay readable to the KVM provider group and no wider; `0644` makes them world-readable,
undoing `/boot` hardening for every local uid on the host.

So the product's own error message instructs the widening its provisioning deliberately refuses to
perform — and it is the message an operator sees at the exact moment they are motivated to act on
it, with root already in hand.

The same string carries two further problems. It says to "re-apply after a kernel upgrade", which is
the manual step that exists only because nothing re-establishes the mode automatically. And it
offers `dpkg-statoverride` as the durable alternative, which cannot work for this at all.

## Evidence

- `src/kdive/images/planes/_build_common.py:81-85` — `_KERNEL_REMEDIATION`:

```python
_KERNEL_REMEDIATION = (
"the libguestfs appliance cannot read the host kernel — Debian/Ubuntu ship "
"/boot/vmlinuz-* as root:0600. Make them readable (run as the worker user): "
"`sudo chmod 0644 /boot/vmlinuz-*` (re-apply after a kernel upgrade, or use dpkg-statoverride)"
)
```

- `src/kdive/images/planes/_build_common.py:94-96` — `_remediation_for_stderr` returns that string
whenever `_KERNEL_UNREADABLE_RE` matches, so it reaches the operator as a
`CONFIGURATION_ERROR` remediation rather than sitting in a comment.

- `deploy/ansible/roles/local_worker_host/tasks/boot_kernels.yml:2-11` — the provisioning role's
reasoning, ending: *"Narrowing an already-0644 Debian host to 0640 is the intended direction, not a
regression — no path here may reach 0644."* The role applies `group: kvm`, `mode: "0640"`.

- `deploy/ansible/roles/live_vm_host/tasks/main.yml` — the second relabel site uses the same
`0640 root:kvm`, with its own comment stating `0644` would *"undo /boot hardening for every local
uid."*

**`dpkg-statoverride` cannot do what the string suggests.** `dpkg` stores an override path
**literally**, not as a glob, so an entry for `/boot/vmlinuz-*` matches no real kernel file and
silently does nothing. This was verified by construction while working #2567: adding
`--add root kvm 0640 '/boot/vmlinuz-*'` listed back verbatim as the literal string, and a kernel
install ignored it.

There is direct evidence someone has already followed this advice and been misled by it: a
development host carries a stale statoverride entry `root root 644 /boot/vmlinux-*` — literal path,
matching nothing, and at the forbidden mode.

## Expected

The remediation an operator is shown matches what provisioning does: `0640 root:kvm`, group-scoped
rather than world-readable. It does not recommend a mechanism that cannot work. It does not present
"re-apply after every kernel upgrade" as the answer where the supported path re-establishes the mode
itself.

## Proposed approach

1. Change the remediation to the group-scoped mode the roles apply — `sudo chgrp kvm /boot/vmlinuz-*
&& sudo chmod 0640 /boot/vmlinuz-*`, with the operator needing to be in the `kvm` group — and
state that as the reason rather than leaving `0644` as a shortcut.
2. Drop the `dpkg-statoverride` suggestion, or replace it with a form that actually works. A literal
per-version path would work but has to be re-added per kernel, which is worse than the supported
path.
3. Point at the supported path instead of the manual one: `just prepare-local-libvirt-host` applies
the relabel, and a `/etc/kernel/postinst.d` hook re-establishes it on upgrade. Mention the
Debian-family scope, since the role is guarded on it and Fedora ships these world-readable
already.
4. Add a test pinning the remediation string against the mode the roles apply, so the two cannot
drift apart again. This issue exists because nothing connected them.

## Out of scope

- The relabel mechanism itself, and whether a postinst hook is the right vehicle.
- The duplicate relabel in `live_vm_host`.
- Retrofitting hosts that already carry a widened mode or a stale statoverride entry — an operator
runbook step, not code.

## Provenance

Found while implementing #2567, which installs a `/etc/kernel/postinst.d` hook so the relabel
survives a kernel upgrade. Reported as adjacent and outside that issue's frozen surface, with the
note that it is "arguably worse than #2567 itself: it instructs the widening." The `0644` mode, the
prohibition it contradicts, and the `dpkg-statoverride` mechanism were each verified independently
before filing. Filed at the repository operator's explicit request.

Start in src/kdive/images/planes/_build_common.py at _KERNEL_REMEDIATION and _remediation_for_stderr, then read deploy/ansible/roles/local_worker_host/tasks/boot_kernels.yml and the live_vm_host task for the supported 0640 root:kvm settings. Update the remediation for the Debian-family path, remove the ineffective dpkg-statoverride advice, and add a test that keeps the message aligned with provisioning.

Written by the indexing model from the issue text.