Define the Odorobo VM manifest contract

[halfcyan]

Summary

Define the stable Odorobo VM manifest that abstracts VM intent from Cloud Hypervisor configuration.

Scope

• Specify CPU, memory, disks/volumes, networks, placement metadata, boot behavior, cloud-init, and vsock fields.
• Identify desired state versus observed runtime state.
• Define validation and unsupported-field behavior.
• Add representative JSON fixtures for minimal, storage-backed, networked, cloud-init, and vsock VMs.

Tasks

• Inventory the existing VirtualMachine, VMData, and Cloud Hypervisor configuration fields.
• Define the manifest schema for CPU, memory, disks, volumes, networks, placement, boot behavior, cloud-init, and vsock.
• Document which fields are desired state and which fields are observed runtime state.
• Define validation rules and unsupported-field behavior.
• Explicitly allow the manifest to evolve before the Proxmox-to-Odorobo migration; do not add compatibility layers for unreleased Odorobo formats.
• Add JSON fixtures for minimal, storage-backed, networked, cloud-init, and vsock VMs.
• Add schema/serialization tests for the fixtures.
• Update the manifest documentation with examples.

What this should do

• The manifest format is documented with examples.
• Every supported field has defined conversion/ownership semantics.
• Invalid combinations produce a clear validation error.
• Fixtures can be used by conversion tests.

Related issues

• Builds on Refactor CH module into separate component #24 (CH module abstraction).
• Provides the contract needed by VM Agents: Configuration #16 (VM agent configuration).
• Related to Metadata Service #25, Generate cloud-init/Ignition configs #26, and Cloud-Hypervisor RVA23 Support #29.

Issue links

• Foundation for #99, #100, #104, and #106.
• Related to existing #16, #24, #25, #26, #28, and #29.