Fix input data checks for azure attestation

[ameba23]

This PR hardens Azure attestation verification by enforcing full 64-byte input binding (cert_hash || tls_exporter) on the verifier side.

Previously, Azure verification validated internal evidence consistency and vTPM nonce binding for only the first 32 bytes. This change adds an explicit check that HCL runtime claims user-data exactly matches the local expected_input_data (64 bytes), preventing cross-session replay where exporter bytes differ.

Security impact

• Restores session-freshness semantics in Azure path to match the intended 64-byte attestation input model.
• Converts ambiguous/missing user-data into hard verification failures.
• Prevents accepting Azure attestations whose embedded input is not equal to verifier-local expected input.

Code changes

• In Azure verifier (verify_azure_attestation_with_given_timestamp):
  • Parse user-data from HCL claims.
  • Hex-decode and require exact 64-byte length.
  • Compare against expected_input_data; return error on mismatch.
• Updated HclRuntimeClaims.user_data type to Option.
• Added MaaError variants:
  • Hex(#[from] hex::FromHexError)
  • ClaimsMissingUserData
  • ClaimsUserDataBadLength
  • ClaimsUserDataInputMismatch

Tests

• Updated positive test to derive the expected input directly from the fixture’s HCL user-data.
• Added negative test test_verify_fails_on_input_mismatch:
  • Mutates one byte in expected input.
  • Asserts verifier returns MaaError::ClaimsUserDataInputMismatch.

Backward compatibility

• No public API signature changes.
• Behavior is stricter by design: malformed/missing/mismatched HCL user-data now fails verification.