fix(cloud-agent): key repository captures with the start image

[eshurakov]

Summary

Repository capture used the current configured image for its key. A container kept running across an image change could publish its old filesystem under the new image key.

Record the selected image before native start. Use that stored image for capture after reconstruction or deployment. Legacy running records without an image skip capture until their next allocation.

Verification

No manual provider test ran. No real provider target is authorized. The local regression reproduces the wrong key before the fix and observes the stored KV key after the fix.

Visual Changes

N/A

Reviewer Notes

Independent B1 prerequisite for runtime rollout step 2. Base: main. This PR must merge before runtime-free image qualification.

Automated checks: 210 container tests passed; Worker and wrapper typecheck passed; focused lint, formatting, and diff checks passed. The image-change regression includes Durable Object reconstruction. Real Cloudflare image rollout and snapshot behavior remain provider acceptance work.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The change records the allocation's start image on the containers record and keys repository captures with it instead of the current configured image; the storage, start, resume, and capture paths are consistent, and the new tests cover the image-change and legacy-record cases.

Files Reviewed (3 files)

• services/cloud-agent-next/src/sandbox-containers/SandboxContainers.ts
• services/cloud-agent-next/src/sandbox-containers/sandbox-containers.test.ts
• services/cloud-agent-next/docs/control-plane.md

Verification notes

• startImage is persisted in the launching record written by issueNativeSupervisor before the physical start (SandboxContainers.ts:393-407), and writeRunning/markWrapperAttempt/installLaunchInstance spread the latest record, so it survives to the running state; terminalRecord drops it on stop, preventing stale reuse by a later allocation.
• Both repoSnapshotIndexKey call sites now use the recorded start image: the lookup uses the current configured image (SandboxContainers.ts:459) and capture uses record.startImage (SandboxContainers.ts:1293). The lookup/capture keys stay consistent by induction, since a hit snapshot is always stored under the image later recorded as the start image.
• The capture gate replaces isRunningAllocation with an equivalent inline check plus startImage !== undefined, and the post-snapshot liveness re-check is retained (SandboxContainers.ts:1273-1292). A declined capture only logs capture_declined in sandbox-do.ts:4726-4761, so skipping a legacy allocation is not treated as a failure.
• ResolvedStart.image is populated on every construction (image and repository branches) and only used for capture keying and startOptions (startOptions ignores it when a containerSnapshot is supplied).
• Existing assertions are toMatchObject/terminal-record toEqual only, so the added startImage field does not break them.

---

_{Reviewed by deepseek-v4.1-flash · Input: 74.9K · Output: 13.9K · Cached: 1M}

_{Review guidance: REVIEW.md from base branch main}