feat(vm): cocoon vm clone --nics N to override snapshot NIC count

[CMGS]

Summary

Adds --nics N flag to cocoon vm clone to override the NIC count inherited from the snapshot at clone time. -1 (default) keeps inheritance behavior.

Why

The new cocoon vm net (PR #42) allows runtime NIC resize on running VMs — but only when CH was started with at least 1 NIC. CH process's netns is decided at boot:

// hypervisor/cloudhypervisor/start.go
if withNetwork && rec.NetworkConfigs[0].NetnsPath != "" {
    netnsPath = rec.NetworkConfigs[0].NetnsPath
}

A VM resized to 0 NICs → snapshot'd → cloned ends up with CH in host netns because NetworkConfigs is empty. A later vm net --nics 1 creates per-VM-netns plumbing CH cannot reach (it ends up making a phantom TAP in host netns, no traffic flows).

Linux + CH doesn't allow changing another process's netns from outside, so we can't fix it at vm net time without breaking the netns boundary (persisting BridgeDev, adding NetnsPath to VMRecord, etc.).

This PR sidesteps the problem cleanly: at clone time the user picks the NIC count. If they want to recover networking after a zero-NIC snapshot, clone --nics 1 puts the new clone on the standard "started with N NICs" path, CH lands in the per-VM netns at boot, and vm net resize later works as designed.

Also updates the vm net zero-NIC error to point users at this new flag.

Tested

• cocoon vm clone --nics 1 SNAPSHOT_WITH_0_NICS on a Linux OCI ubuntu produces a clone with the expected per-VM netns + working DHCP.
• cocoon vm clone --nics 0 on a snapshot with NICs strips them at clone (intentional zero start; can't resize up later, consistent with vm run --nics 0).
• cocoon vm clone SNAPSHOT (no --nics) preserves snapshot's NIC count (unchanged behavior).
• make lint + go test ./... green.

Test plan

• Lint + tests
• Manual: clone zero-NIC snapshot with --nics 1 and verify DHCP
• Manual: clone with --nics 0 and verify VM has no networking
• Manual: clone without --nics inherits as before

🤖 Generated with Claude Code