[cdalar]

Summary

Step 1 of rootfs-diff-export-import.md (a boxctl-vms plan doc, whose core diff/patch approach was already manually verified byte-for-byte against a real paused VM on aimax).

• fcVM now records BaseImagePath/BaseImageSHA256/BaseImageSizeBytes at Deploy time.
• New BaseImageIdentifier interface, kept separate from RootfsPreparer itself — Cloud Hypervisor's preparer (internal/providerch) has no equivalent export path (diff-export is Firecracker-only, matching Service.Pause's existing ch/Windows rejection) and shouldn't need to implement a method it'll never use. ProviderFC.Deploy type-asserts for it instead of requiring it.
• DebugfsRootfsPreparer.BaseImageIdentity caches the sha256 in a {baseImage}.sha256sum sidecar file, invalidated by mtime/size change, so repeated Deploys against the same golden image don't re-hash a multi-GB file every time. Reuses ensureCacheImage's existing file-lock helper (renamed lockCacheImage → lockPath, now used by both).
• A failure to compute base-image identity is soft: logged, never fails Deploy — this is purely an optimization for a later, unrelated export feature.

No CLI changes, no behavior change for anyone not consuming the new fcVM fields.

Test plan

• go build ./...
• go vet ./...
• golangci-lint run on touched packages — 0 issues
• New unit tests: hashFile, baseImageIdentity (cache-hit via corrupted-sidecar check, and cache-invalidation on mtime/size change), Deploy populating the new fields, and Deploy's soft-fail path when identity computation errors
• Full suite (go test ./...) — one pre-existing failure in ./cmd (TestReadConfig_NoConfigDirectory, TestCreateFlagsBindToViper) confirmed present on main before this change too (via git stash), unrelated to this PR

🤖 Generated with Claude Code

https://claude.ai/code/session_01LFu9nLXeUeopfwaqpyMcD6

[cdalar]

The Analyze (actions) CodeQL check failed, but it's not this PR's — the diff here is Go-only (internal/providerfc/common.go, internal/providerfc/common_test.go, pkg/cloud/fc.go, pkg/cloud/fc_test.go), no .github/workflows/** or other Actions-related files touched. The job's own log shows the query evaluation completing normally; the failure is in the SARIF upload step afterward ("Uploading failed SARIF file..." / "CodeQL job status was failure"), and the same check type passed cleanly on the previous PR (#1120) with an identical setup — pointing to a transient upload hiccup rather than a real finding.

I tried to re-run just that job to confirm the flake, but it's part of GitHub's managed default CodeQL setup and the Actions API refuses a retry (403: This workflow run cannot be retried), so I can't force it. No fix exists on this PR's side — will keep watching in case it clears on the next push or a maintainer re-triggers it manually.

---

Generated by Claude Code