feat: export and push cloud images to OCI

[czmDeRepository]

Summary

• push snapshots to OCI without changing clone/restore snapshot semantics
• export Cloud Hypervisor cloud-image VMs as standalone qcow2 OCI artifacts
• import and export local cloud images for host-to-host transfer
• skip blobs that already exist in the registry

VM export behavior

A running VM is stopped under its lifecycle lock, its root qcow2 backing chain is flattened, and the VM is restarted before the registry upload begins. A VM that was already stopped remains stopped. Direct-boot filesystems and additional data disks are intentionally outside this export format.

Local file export uses a synchronized temporary file and atomic rename, so a failed copy does not truncate an existing image. If OCI publication succeeds but optional local retention fails, the command reports the published manifest digest instead of presenting the operation as a total failure.

Artifact semantics

Snapshot push preserves memory, device, disk, CPU, and guest topology state for compatible clone/restore consumers. VM export produces a portable system-disk artifact for a fresh vm run; it does not carry runtime memory state.

Validation

• make lint
• go test ./cmd/vm ./cmd/images ./cmd/snapshot ./images/cloudimg ./hypervisor/cloudhypervisor
• go test ./...

[CMGS]

thanks for the work here, but we're not taking this direction. two reasons.

layer boundaries: registry push is the orchestrator's job in our stack. whoever consumes a snapshot pushes it, cocoon stays digest self contained and only pulls. pulling belongs here because clone has to materialize images on the node, pushing doesn't serve any cocoon operation.

don't duplicate existing mechanisms: vm export is a strict subset of what snapshot save/export/import/clone already covers (no memory state, no data disks, cloudimg only), and building goldens goes through snapshots too. images export has no consumer, images enter the store via pull or import so the source always exists on the producing side already.

if you hit a concrete workflow the snapshot family doesn't cover, please open an issue describing it first so we can discuss where the mechanism belongs.

[CMGS]

btw for the transfer use case you don't need new code at all. cocoon snapshot export gives you a portable archive, and oras can push that to any registry as an artifact (oras push reg/repo:tag snap.tar), crane does the same for plain qcow2 blobs and images. that plus snapshot import / images import on the other side covers host to host today, and keeps the registry side in standard tools instead of cocoon.