metal: procure + enable SEV-SNP capability on the hosted bare-metal fleet

[JSONbored]

Problem

#8137 recorded the one actionable-now output of the TEE survey: when the bare-metal purchase for the hosted execution plane happens, AMD EPYC with SEV-SNP (Milan or newer) + BIOS/firmware SNP enablement is a hard selection criterion — it costs nothing extra at purchase time and keeps the attested-evaluation door open with zero infra split. Nothing tracks actually executing that criterion end to end: purchase, firmware enablement, kernel prerequisites, and proof the SNP stack works.

Requirements

• Hardware selection for the hosted bare-metal fleet enforces: AMD EPYC Milan or newer with SEV-SNP support, and a vendor/BIOS combination with documented SNP firmware enablement.
• Enablement per host: SME/SEV/SEV-ES/SEV-SNP BIOS settings, SNP firmware at a supported version, host kernel ≥ 6.11 (the Kata SEV-SNP guide's floor).
• Validation per host: snphost ok (or equivalent platform check) passes; a minimal SEV-SNP guest launches and produces an attestation report.
• The enablement runbook lives in the private infra documentation, not this repo — no hostnames, IPs, vendor account details, or inventory in public text.

Deliverables

• At least one SNP-enabled host live and validated
• Redacted validation evidence (tool output, versions — no host identifiers) recorded as a comment here
• The CoCo runtime-class sub-issue unblocked

Links & Resources

• Research: survey viable TEE/confidential-compute options on Cloudflare Workers/Containers #8137 (the survey that fixed this criterion), Provisioning core: create/destroy a tenant's Container + Postgres DB #7180 (the k3s/Kata stack this hardware runs)
• Kata Containers SEV-SNP how-to (kernel ≥ 6.11 floor); AMD SNP host tooling (snphost)

Boundaries

Hardware + firmware + validation only — no k3s/CoCo deployment (next sub-issue), no application changes, nothing in this repo's code.

maintainer-only — infrastructure procurement and host access.

[linear-code]

JSO-5904