Secure Boot phase 3: zero-touch db enrolment out of band, and OEM db enrichment

[mastacontrola]

Split out of #134, which is now closed — phases 1 and 2 shipped
and were validated on firmware. This is the work that was listed there as
"Phase 3" and never started.

Where phase 2 leaves things

Setup Mode enrolment (fos#135, FOGProject/fogproject#990) removed the USB stick,
the live image, the fingerprint transcription and the MokManager password. What
it did not remove is the one firmware visit: somebody has to clear the platform
keys to put the machine into Setup Mode before FOG can write anything.

That is one BIOS screen, once per machine, ever — and it can be the same trip
that enables Secure Boot. For most sites that is an acceptable answer. It is
still not zero-touch, and for a large fleet or remote sites it is the whole cost.

1. Out-of-band db write — the only genuinely zero-touch tier

db/KEK/PK can be written with the client powered off, over the BMC:

• Redfish — /redfish/v1/Systems/{id}/SecureBoot and its
  SecureBootDatabases collection. Vendor-neutral where it is implemented.
• Dell — cctk / Dell Command | Configure for desktops and laptops that have
  no BMC, iDRAC for servers. Dell is the vendor confirmed to expose programmable
  custom-mode PK/KEK/db import.
• Lenovo — clearing PK into setup mode is supported; whether Think BIOS
  Config can push certificate blobs unattended is unconfirmed.
• HP — commercial unconfirmed; consumer lines have no enrolment mode at all.

No boot, no OS on the client, no physical presence. This should be documented as
a first-class tier alongside Setup Mode rather than as a follow-on, because for
anyone who has it, it is strictly better than everything else FOG offers.

Open questions before building: where credentials live (a BMC credential per host
is a new secret store FOG does not currently have), whether this belongs in a task
type at all given the client never boots, and how the result is reported when
there is no FOS to report it.

2. Capture-as-enrichment for OEM db entries

Phase 2 ships Microsoft's published CAs as the db baseline. That was the right
call — capturing each machine's factory keyset as the baseline was rejected in
#134 because it has no answer for the first machine of a model, it is an ordering
trap the admin cannot recover from, and restoring a stale dbx re-trusts revoked
bootloaders.

What it loses is the OEM-specific entries: Dell SupportAssist, HP Sure Recover,
Lenovo diagnostics. Those live in the factory db and a machine enrolled with
FOG's baseline no longer trusts them.

The intended shape is capture as enrichment, not as baseline: read the existing
db before overwriting, keep entries that are not in the Microsoft set, and merge
them into what gets written. dbx stays out of the shipped bundle either way.

Wants a decision on whether merged entries are per-model or per-host, and what
happens on a machine whose db was already replaced by something else.

Not in scope

32-bit UEFI — separate issue, decided as refuse.