feat(restore): restore VM from :hibernate on cross-node create

[tonicmuroq]

Lets a hibernated VM come back on a different node instead of booting fresh from the base image — the core capability behind cross-node migrate.

What

• CreatePod/bringUpVM gains a first-priority restore branch (gated on the restore-from-hibernate annotation): resolves the :hibernate snapshot (local or pulled from epoch) and clones from it, rather than from spec.Image.
• Extracts wake()'s restore core into shared cloneFromHibernate + dispatchHibernateRestore — so the cross-node path reuses the exact same logic, including the CH+Windows 0-NIC --nics 1 hot-add and the "wait for the fresh NIC's DHCP lease, no PnP recycle" post-step. wake() refactored to call them (behavior-preserving).
• A Windows restore therefore hot-adds the NIC and does not redundantly recycle.

Dependency

Depends on cocoonstack/cocoon-common#3 (the restore-from-hibernate annotation). go.mod currently pins the branch commit via pseudo-version; bump to the cocoon-common release tag after #3 merges.

Tests

restore_test.go (Windows hot-adds NIC / Linux inherits); full suite + make lint clean on linux + darwin.

[CMGS]

Rebased onto main (code-style cleanup + dep bumps). The deps commit became a no-op — main is already on common v0.2.2 / epoch v0.2.4, both of which carry AnnotationRestoreFromHibernate — so it dropped, leaving 2 commits.

The create.go + update.go changes were auto-merged onto a reorganized codebase, so I verified the merge is intact: cloneFromHibernate / dispatchHibernateRestore / finalizeDropNICWake / wake / bringUpVM are each defined exactly once, the restore branch is the first bringUpVM case, and restoring is consistently gated (dispatch / skip-SAC / skip-base-post-clone / defer-Ready). build / vet / test (incl. restore_test + delete_test) all green. No correctness must-fix — the restore flow is solid.

One metric-consistency call for you (non-blocking):

dispatchHibernateRestore's CH+Windows (dropNIC) branch returns before the op=="update" gate and delegates to finalizeDropNICWake, which unconditionally bumps WakeTotal / WakeIPWaitTotal. So a cross-node create restore of CH+Windows counts into wake-specific metrics, while the Linux create-restore path (gated) does not. It's a semantics judgment — should cross-node restore count as wake or create? Either (a) op-gate finalizeDropNICWake's metric bumps, or (b) accept restore as uniformly "wake" (then the Linux path is the odd one out).

Two nits while you're in there: VMBootDuration label is spec.Mode on create-restore vs "clone" on wake; and the -hibernate-import copy leaks if a cross-node pull succeeds but the subsequent Clone fails (pre-existing wake pattern, inherited here — separate cleanup).

Otherwise #24 is merge-ready.