perf: singleflight same-ref OCI snapshot and cloud-image imports

[CMGS]

Problem

Concurrent Pods using the same cold OCI artifact can independently download and import the same bytes. The check-and-pull/import sequences are not synchronized:

• snapshot check and pull: ensureSnapshot
• cloud-image resolution and import: ensureRunImage
• full artifact streaming: snapshots/puller.go

Snapshot import also removes the existing local name before starting. A cold burst can therefore perform N registry transfers/imports and race on the same local destination. A previous implementation identified this corruption class in vk-cocoon#1, but the protection was lost during the OCI-path rewrite.

The provider already has the desired singleflight pattern for fork snapshots in ensureForkSnapshot.

Proposed scope

• Add provider-owned keyed singleflight around the complete local-check + transfer/import + post-check sequence.
• Use separate key namespaces for snapshots and images, keyed by local destination/ref.
• Keep the local-hit fast path and let different artifacts import concurrently.
• Detach shared work from an individual CreatePod cancellation, with a bounded provider-lifecycle context.
• Preserve force-pull semantics: concurrent force requests share one active import, while a later force request can import again.

Acceptance criteria

• 16 concurrent cold requests for one snapshot produce one registry stream and one snapshot import.
• 16 concurrent cold requests for one cloud image produce one registry stream and one image import.
• Different refs are not serialized behind each other.
• A local cache hit performs no transfer or import.
• Cancelling one waiter does not cancel shared work for remaining callers.
• A shared failure reaches every waiter and a later call can retry successfully.
• Tests pass under go test -race.
• A cold-cache burst benchmark records registry bytes, import process count, and CreatePod p95 before and after.

[CMGS]

Code merged in #37 (main 2e26f64). Status against acceptance criteria:

Met (unit + -race, deterministic via testing/synctest):

• ✅ 16 concurrent cold requests → one import (snapshot: TestEnsureSnapshotColdBurstSingleflight; image: TestEnsureRunImageColdBurstSingleImport), one manifest fetch asserted.
• ✅ Different refs not serialized (TestEnsureSnapshotDifferentRefsNotSerialized).
• ✅ Local cache hit performs no transfer or import (TestEnsureSnapshotLocalHitSkipsRegistry, TestEnsureRunImageWarmHitNoImport).
• ✅ Cancelling one waiter does not cancel shared work (TestEnsureSnapshotSharedWorkSurvivesCallerCancel) — plus Close() aborts the detached import (TestEnsureSnapshotSharedImportAbortedByClose). Both were verified to fail against a plain Do+WithoutCancel shape before being kept.
• ✅ Shared failure reaches every waiter and a later call retries (TestEnsureSnapshotRetryAfterSharedFailure).
• ✅ go test -race -count=20 green.

Design note: the issue's "corruption class" premise did not hold against current cocoon (imports extract into a unique dir; the name is bound only on completion via a collision-checked insert). The real harms fixed are the availability failure (N-1 of N concurrent cold clones failed "snapshot name already in use") and N× wasted registry bytes. The referenced vk-cocoon#1 was CLOSED / never merged.

Pending (hardware, not yet run):

• ⬜ Cold-cache burst benchmark: registry bytes, import process count (execsnoop), CreatePod p95, and "name already in use" failures ~15 → 0, before/after.

Keeping open until the testbed burst run lands.