fix(attest): accept one vm_config, not competing copies

[kvinwang]

Problem

A reader could find the VM config in more than one place, and different readers picked different copies:

• Request vs attestation. KMS RPCs and the verifier receive a vm_config alongside an attestation that also carries one. Readers took the request copy whenever it was non-empty and never compared it with the attested one.
• Top level vs nested. dstack-attest and dstack-mr also accepted a sys-config-shaped config, with the real config serialized under a vm_config key. The SEV-SNP parser in dstack-mr preferred the top-level fields, while the decoder in dstack-attest let the nested string replace the whole config. No producer in this repo emits that shape: attestations and requests both carry the flat sys_config.vm_config.

On SEV-SNP the second split is exploitable. Suppose a SignCert request carries the genuine top-level os_image_hash plus a nested {"os_image_hash": <other>}. Authorization checks the genuine hash against the launch measurement, and the certificate's app-info extension then claims <other>.

Fix

• dstack_attest::resolve_vm_config(external, embedded): with one copy, use it; with two, require them to be identical. decode_vm_config, the SEV-SNP app-info decoder, the KMS SNP boot-info path and the verifier's launch binding all go through it.
• Drop the nested vm_config shape from dstack-attest and dstack-mr, so a config has one layout and every field has one source. Inputs in the nested shape no longer parse.

Honest requests are unaffected, because every in-tree caller fills both copies from the same sys_config.vm_config string.

Verification

• New KMS test: build_boot_info_for_attestation rejects a request vm_config that differs from the attested one and accepts an identical copy.
• cargo test --all-features passes for dstack-attest, dstack-mr, dstack-kms and dstack-verifier. cargo check --workspace --all-features --tests passes, and clippy (-D warnings) is clean on the touched crates.