feat: cold-relaunch managed macOS guests on reboot

[czmDeRepository]

Problem

A macOS warm reset can stall indefinitely during early boot under QEMU/KVM. The QEMU process remains alive, so an external owner cannot distinguish the stalled guest from a healthy reboot and cannot recover it reliably.

Consumer

The consumer is vk-cocoon. Its macOS provider passes --exit-on-reboot when creating managed guests and, after observing the QEMU exit, recovers the persisted VM record with cocoon-macos vm start.

Fix

• add --exit-on-reboot to create / run / clone only
• translate the persisted policy to QEMU's -no-reboot
• inherit the policy during clone unless explicitly overridden
• keep normal in-process reboot behavior as the default for standalone VMs
• document that the QEMU exit skips normal vm stop cleanup and recovery must use vm start

This policy is independent of watchdog-based hang recovery.

Validation

• go test ./...
• make fmt-check vet lint
• warm-reset testbed observation pointer: pending

[CMGS]

mechanically clean, but this is a feat, not a fix — nothing existing was broken for standalone vms; it adds a policy knob for an external supervisor. two asks before the code details matter:

• name the consumer: which supervisor consumes the qemu exit, and where does that integration land? without a named consumer this is a speculative flag.
• the 'warm reset can stall indefinitely during early boot' claim is the entire justification — where was it observed (host, guest version, frequency)? a pointer is enough.

also worth one line in docs/cli.md: the -no-reboot exit path skips vm stop's cleanup — tap stays un-quiesced and a cni+vnc proxy stays alive — same as any qemu crash today, fine as long as the supervisor's recovery is vm start (which reaps both), but the contract should say that.

retitle to feat: for the squash. heads up: #28/#29/#30 all collide in qemu/launch.go and cmd/vm/lifecycle.go — expect rebases in whatever order they land.

gates on 11f767e: make lint (linux+darwin) 0 issues, asl ./... clean on both GOOS, go test ./... green.

[CMGS]

all items landed: create/clone-only, one-line comment, docs state the no-cleanup exit + vm start recovery, title is feat:. consumer checks out — vk-cocoon's provider/cocoon/macos.go is real (its #68), so the knob stands on the supervisor contract alone.

last open item is the 'warm reset can stall indefinitely' claim, still marked pending. either attach the pointer, or stop asserting it — see inline for the reworded comment. then this is an approve. gates on 806e1c2: lint (linux+darwin) 0 issues, asl ./... clean both GOOS, go test, vet.

[CMGS]

if the stall observation isn't going to be attached, don't encode folklore in the comment — state the contract instead: // supervisor-owned guest: a reboot request exits qemu so the owner relaunches it cold. same for the 'Problem' paragraph in the body.