Offer kernel updates once a kernel is validated against drivers

[DaniusKalv]

Frozen kernels (#47) mean a kernel only moves when a specific one is known good against the whole driver set. That needs a signal from the archive and a gated flow on the box.

• Archive side: publish which kernel is validated. A camlab-kernel-validated metapackage whose Depends pins the validated linux-image version keeps the logic in the apt resolver, with no bespoke protocol or signature scheme to invent
• On the box, one gated sequence: unhold, upgrade, let DKMS rebuild every sensor module, verify each one loads for the new kernel, re-hold, and reboot only if all of that passed
• Separate system update action in the GUI, never a row beside the per-driver rows. Per-driver updates are cheap and reversible, this one can cost the cameras
• Needs the update flow from Add camlab-update shim and offline-update apply #45 and the updates card from Add updates card with per-component versions and selective update #48

[DaniusKalv]

Hardware validation of #47 settled a constraint that shapes this one.

apt-mark hold and unhold only stick inside a writable boot. A hold changed while the root is locked evaporates on the next boot, so a kernel update cannot be spread across boots. Unhold, kernel upgrade, DKMS rebuild and re-hold all have to happen inside one writable window, which is exactly what the update boot in #45 provides. Whatever this issue builds should run there rather than as its own path.

Still unverified: a live sensor binding after a DKMS rebuild. The #47 run had no sensor attached, so the update system handover covers it.