feat: slot-release hibernation for hibernatePolicy=release CocoonSets

[tonicmuroq]

Why

A hibernated VM's placeholder pod keeps its CPU/memory requests bound to the node, so the scheduler counts the seat as occupied even though vk-cocoon has pushed the VM to the registry and destroyed it locally. On a node with 60/80 VMs hibernated, 60 seats are dead weight: no new VM can take them and the live VMs run effectively un-oversold. hibernatePolicy=release turns hibernation into "give the seat back to the pool" — wake takes any free seat on any node, exactly like a GCE create can hit a zone stockout.

Design: https://github.com/cocoonstack/cocoon-specs/pull/5. Depends on cocoon-common: cocoonstack/cocoon-common#7 (merged; go.mod pinned to its merge commit 4363e4f).

How

All new logic in cocoonset/slotrelease.go, two insertions in Reconcile:

• reconcileSuspendRelease (replaces reconcileSuspend for release sets): applies the hibernate annotation as before, then — only after the existing allOwnedPodsHibernated gate (lifecycle-state=hibernated ∧ observed-generation ≥ CR generation ∧ snapshot present in registry) — stashes the vm names (reusing the delete-time GC stash) and the main pod's node (wake hint) onto the CR, and deletes the owned pods. Terminal pods are kept for the existing post-unsuspend triage. Fails closed without a registry: the seat is never released unverified.
• reconcileWake: owns the reconcile of a pod-less Suspended set coming back. Persists the new Waking phase before creating the restore pod (crash re-entry resumes the restore instead of falling through to createMainAgent, whose restore intent only covers CocoonHibernation CRs and would fresh-boot over the snapshot). The pod is created unpinned with restore-from-hibernate and a preferred (soft) affinity to the hibernated-on node — old seat still free ⇒ warm wake from the node-local snapshot, otherwise the scheduler places it anywhere in the pool and vk pulls from the registry. Unschedulable surfaces as WakeNoCapacity events + a metric while the pod keeps waiting. Suspended lands in the same pass as the deletes (the durable receipt); a fast unsuspend that still sees the old main in a stale cache is confirmed against the uncached API (stale view of the delete → wait, never-deleted pod → in-place wake), and a crash before the receipt leaves pod-less Suspending which the node-hint arm restores — no informer ordering can reach a fresh boot over the snapshot. The :hibernate tag is dropped only once the restored VM is live (same rule migration enforces). Gated on phase, never on the current policy or bare tag presence, so a policy edit made while suspended still restores correctly and a stale tag can never roll a running VM back.

Migration is unaffected and runs first: a pinned released set resumes through migration's aborted-migration branch, so a spec.nodeName pin always wins over wake-anywhere.

Metrics

slot_release_pods_deleted_total, slot_release_wake_total{placement=hint-node|pool} (soft-affinity hit rate — note every release wake restores via registry pull: vk drops local snapshots with the pod, so hint-node placement is about future warm-path potential, not a warm restore today), slot_release_wake_unschedulable_total (the out-of-stock signal for fleet sizing).

Tests

21 new cases in cocoonset/slotrelease_test.go (fake-client style, mirroring migrate_test.go): verify-before-delete ordering, stash-before-delete, terminal-pod retention, restore+preferred-affinity pod shape, pin-wins-over-hint, fresh-boot fallthrough when no snapshot exists, fail-closed probe errors, tag survival until live, Running-phase tag distrust, and normal-flow handoff for retain placeholders. Full go test ./... green.