feat: automate Azure SNP platform-constant collection via snpguest --openhcl

[butler54]

Summary

overrides/values-trustee-azure.yaml (added in #130) pins the current kbs.azure.* Azure SEV-SNP platform constants (snpLaunchMeasurement, smtEnabled, tsmeEnabled, abiMajor, abiMinor, singleSocket, smtAllowed) explicitly, but there's still no automated way to collect or verify these values against a real deployment. This issue tracks building that collection tooling.

Background

These values describe the SEV-SNP policy Azure enforces for a given confidential VM series. They are not measurements veritas can compute from any artifact (confirmed: docs/firmware-reference-values.md's "Known Limitations" already documents this as a veritas gap). The only documented method today is manual: "check the trustee logs for the actual values reported by the VM and update these" (per trustee-chart's values.yaml comment) — with no documented log format or grep pattern to actually do that.

Proposed collection path

Research findings (see #130's discussion for full detail):

1. coco-pattern already has a dormant SSH-debug-into-podvm feature: global.coco.enableSSHDebug + COCO_ENABLE_SSH_DEBUG=true ./scripts/gen-secrets.sh + sandboxed-containers-chart's ssh-key-eso.yaml (Azure-only, opt-in). This is the same underlying mechanism as the separate podvm SSH key tracked in chore: modernize podvm SSH-debug key to support Ed25519 alongside RSA #129.
2. virtee/snpguest (actively maintained upstream Rust CLI) has a documented --openhcl mode specifically for reading SNP attestation reports through Azure's paravisor from inside the guest — this is exactly the evidence type (az-snp-vtpm) Trustee uses for Azure.
3. Proposed script: enable SSH debug, SSH into the podvm, build/run snpguest report attestation-report.bin request-file.bin --openhcl, parse the report's measurement, platform_info (SMT/TSME bits), and policy (ABI major/minor, single socket, SMT allowed bits), and emit a ready-to-use overrides/values-trustee-azure.yaml snippet — mirroring the existing snp-collect-vcek-urls → snp-download-vcek → snp-gen-overrides pipeline style already used for bare-metal SNP VCEK certs.

Why this is a separate issue from #130

This needs validation against real Azure hardware (SSH connectivity to a peer-pod VM, building/running snpguest with the hyperv feature inside it) that wasn't available when #130 was authored. Scoped out to avoid shipping unvalidated tooling in the same PR as the (fully scenario-tested) reference-value collection fixes.

Acceptance criteria

• Script (or Makefile target) that automates report extraction + parsing once SSH access to the podvm is established
• Emits values in the exact format overrides/values-trustee-azure.yaml expects
• Documented end-to-end workflow (enable SSH debug → deploy → SSH to podvm → run collection → update override → redeploy)
• Validated against a real Azure confidential VM