DestinationImageImported never progresses past OVA resolution, status.image is never persisted

Summary

DestinationImageImported never progresses past OVA URL resolution, for both auto-resolved and user-provided OVA URLs. The condition repeats "OVA URL resolved, starting download" indefinitely and the download phase is never reached, so the operator can never manage an RHCOS template import in any configuration.

Reproduction

With spec.image: {} (auto-resolve) or an explicit spec.image.ovaUrl, ensureDestinationImageImported logs a resolved OVA URL roughly every 15 seconds and the DestinationImageImported condition stays False (Progressing) with message "OVA URL resolved, starting download" indefinitely. No download ever starts, no error is ever surfaced. Confirmed empirically that status.image reads back empty on every reconcile:

oc get vmwarecloudfoundationmigration cluster -n openshift-vcf-migration -o jsonpath='{.status.image}'

returns nothing, even minutes after the controller logs have repeatedly reported a resolved URL.

Root cause

updateStatus was refactored to support safe concurrent reconciles across a leader-election handoff. Instead of persisting the whole in-memory status, it re-fetches the object and selectively copies over only the fields it knows how to merge safely: Conditions (condition by condition, with generation and success-downgrade guards), StartTime, and CompletionTime.

When the Image status field was added later for OVA import provenance tracking, the copy in updateStatus was never extended to include it. ensureDestinationImageImported sets migration.Status.Image.ResolvedOVAUrl (and related fields) on the in-memory object in Phase 2, but updateStatus never carries that value onto the object it actually persists, so it is silently discarded on every reconcile. The next reconcile starts from an empty status.image again, needsOVAReresolution reports true, and Phase 2 runs from scratch, forever.

Fix

A pull request is attached implementing the minimal fix: copy migration.Status.Image onto the freshly-fetched object in updateStatus, mirroring the existing StartTime/CompletionTime handling. Verified live on a real cluster that this resolves the stuck condition, and added a test (updateStatus persists status.image...) that fails on current main and passes with the fix.

Environment

• OCP 5.0.0-rc.1, vSphere
• vcf-migration-operator dev-preview build, reproduced against both auto-resolve and explicit spec.image.ovaUrl configurations

Filed from hackathon testing under OCPSTRAT-2677.

Start at updateStatus, where the issue identifies the selective status merge, and review the existing handling for StartTime and CompletionTime. Run the named test, "updateStatus persists status.image...", which currently fails on main; done means status.image is persisted and the test passes.