kms: record OS image version and dev flag on-chain in the next-gen contract

[kvinwang]

Problem

The verifier only reports os_image_is_dev / os_image_version on the TDX legacy path, the one path that downloads the image and reads metadata.json. TDX lite, SEV-SNP, GCP TDX, AWS NitroTPM and Nitro Enclave carry only the manifest digest, so both fields are null there (#1266). Right now relying parties can't tell a dev image from a prod image on those paths, and can't enforce a minimum version. The only thing they can do is keep their own os_image_hash allowlist.

DstackKms already whitelists OS images on-chain, but it stores just a bool for each hash (allowedOsImages), so the chain doesn't know what the hash is.

Proposal

In the next-generation KMS contract, store metadata for each OS image hash, for example:

struct OsImageInfo {
    bool allowed;
    bool isDev;
    string version; // e.g. "0.5.10"
}
mapping(bytes32 => OsImageInfo) public osImages;

• addOsImageHash takes isDev and version, and emits them in the event.
• Every attestation path can look up version and dev status by os_image_hash from the same source. This doesn't need image downloads or metadata.json.
• KMS / relying-party policy can reject dev images or enforce a minimum version from on-chain data.
• The verifier can fill in os_image_is_dev / os_image_version from the contract when the platform doesn't expose them.

The owner who allowlists a hash vouches for its metadata. This is the same trust we already give to the allowlist.

Open questions

• Keep allowedOsImages(bytes32) -> bool as a view for compatibility with existing consumers?
• Should dev images be allowed at all on production KMS instances, or should the contract reject isDev images directly in isAppAllowed?