Encode os.version and os.features with OCI spec keys

[rishabhsai]

Platform declares osVersion and osFeatures, but its CodingKeys only lists os, architecture and variant, so both fields are dropped on decode and never encoded. Image declares the same two fields with no CodingKeys at all, so it decodes nothing for them and writes them out as osVersion and osFeatures. The OCI image spec names these keys os.version and os.features: specs-go/v1/descriptor.go tags OSVersion with json:"os.version,omitempty" and OSFeatures with json:"os.features,omitempty", and config.go embeds Platform in Image, so the config uses the same two keys. Any image that sets them loses that metadata the moment it is parsed. ImageStore+Import.swift:246 builds a Platform from config.osFeatures and always gets nil, and an index re-encoded on export or push comes back missing os.version, which is what containerd and docker match manifests on.

This adds the two spec keys to Platform.CodingKeys with the matching encode and decode calls, gives Image an explicit CodingKeys, and leaves the Swift property names, equality and hashing unchanged. Two round-trip tests in OCIImageTests decode JSON containing os.version and os.features for Platform and Image, assert the values, then re-encode and assert the spec key names appear. Reverting the two source files makes both fail on the decoded values being nil; with the fix in place swift test --filter OCITests passes all 127 tests.

One compatibility note: Image had no CodingKeys before, so JSON written by earlier versions of this package with osVersion or osFeatures set will now read those two fields as nil, which is what the spec-keyed fields already read as before this change. No such JSON is produced in this repo's tests, and registries and containerd only ever emit the spec keys.