fix(sev-snp-qvl): an empty SNP report in a /verify body aborts the verifier

[kvinwang]

dstack-verifier's POST /verify is unauthenticated, and release builds are
panic = "abort" (dstack/Cargo.toml:312-313), so a panic in a parser on that
path is a whole-process abort rather than a failed request. This is one.

What happens

QuoteVerifier::fetch_and_verify takes the AMD KDS branch whenever cert_chain
is empty, and that branch handed the report straight to
AttestationReport::from_bytes. The sev crate reads bytes[0..4] there, and
bytes[392] for a version it does not recognise, without looking at the length
first:

// sev-6.0.0/src/firmware/guest/types/snp.rs:191
let mut version_bytes: [u8; 4] = [0; 4];
version_bytes.copy_from_slice(&bytes[0..4]);   // :193
...
let family: u8 = bytes[392];                   // :200

report and cert_chain are free-form Vec<u8> / Vec<Vec<u8>> in the
attestation envelope (dstack-attest/src/v1.rs:84-88), and the parse runs
before any KDS fetch, signature check or report_data comparison, so an empty
report in the request body is enough:

POST /verify  ->  verification.rs:708  VersionedAttestation::from_bytes
              ->  verification.rs:723  attestation.verify()
              ->  attestation.rs:1151  PlatformEvidence::SevSnp -> fetch_and_verify
              ->  sev-snp-qvl/src/lib.rs:145  AttestationReport::from_bytes

Triggering bodies: report = [], or report = [03 00 00 00] — any report of
4..=392 bytes whose first four bytes are not 0, 1 or 2.

Pre-fix, cargo test -p sev-snp-qvl:

test tests::a_short_report_without_a_cert_chain_is_rejected_rather_than_parsed ... FAILED

thread '...' panicked at sev-6.0.0/src/firmware/guest/types/snp.rs:193:45:
range end index 4 out of range for slice of length 0

and the same abort through the whole request path,
cargo test -p dstack-attest --test sev_snp_verify:

test an_empty_snp_report_from_the_verify_body_is_rejected_rather_than_parsed ... FAILED

thread '...' panicked at sev-6.0.0/src/firmware/guest/types/snp.rs:193:45:
range end index 4 out of range for slice of length 0

The fix

The other three callers of the same parser already rejected anything that is not
1184 bytes — each with its own copy of the check. The bug is that the
precondition was a convention rather than something the parser owned. One
decode_amd_snp_report now checks the length and decodes, and all four callers
go through it, so the next caller gets it right by construction.

Tests

Two regression tests, both of which fail on next with the output above:

• sev-snp-qvl: fetch_and_verify with an empty cert_chain and a 0-, 4- and
  1183-byte report.
• dstack-attest: the real SEV-SNP fixture with its report and cert_chain
  emptied, re-encoded, decoded through VersionedAttestation::from_bytes and
  run through verify — the exact shape of a /verify body.

cargo test -p dstack-mr -p dstack-types -p tpm-qvl -p tpm-types -p dstack-attest -p sev-snp-qvl -p cc-eventlog -p dstack-verifier is green,
cargo clippy -p sev-snp-qvl -p dstack-attest --lib -- -D warnings --allow unused_variables is clean, cargo fmt --all -- --check is clean.
(cargo clippy --all-targets does not pass on next either, so the lib-target
gate is what is used here.)

No measurement byte moves: the change is confined to sev-snp-qvl, which no
measurement path calls. dstack-mr's sev::tests::measurement_vector_does_not_drift,
the inline TDX vectors, and the --ignored tdvf_parse test against the cached
real v0.5.5 image all pass unchanged.

Relation to the other open parser PRs

This came out of a full inventory of the binary attestation and measurement
parsers. Everything else the inventory turned up in this area is either already
bounded or already has an open PR bounding it — #1231 (PE headers), #1236 (TDVF
and the TD HOB witness), #1238 (TPM collateral), #1248 (SNP certificate table),
#1252 (SEV page budget), #1267 (duplicate PCR indices), #1275 (compute_pcr_digest
boundaries and four more), #1249 (the proptest harness and corpus). This is the
one reachable abort none of them covers.

Test-merges: clean against #1231, #1236, #1238, #1252 and #1267. One trivial
conflict each with #1248 and #1249 (both add a const next to
CERT_TABLE_ENTRY_SIZE — keep both). One conflict with #1275, which renames
parse_amd_snp_report to parse_unverified_amd_snp_report in the same place
this lifts the guard out — keep #1275's rename and doc on the public wrapper and
let its body call decode_amd_snp_report. All three resolutions were applied
locally and the suites pass.