Constant SECURITY_CONTEXT_RESOLVED_CONDITION 

pub const SECURITY_CONTEXT_RESOLVED_CONDITION: &str = "SecurityContextResolved";

Snapshot/Restore condition recording whether the mover’s securityContext could be RESOLVED at all — the hold, as opposed to the advisory SecurityContextInherited report of what inheritance achieved on a run that still went ahead.

Set False (with INHERIT_SOURCE_MISSING_REASON) when mover.inheritSecurityContextFrom names a live-pod source that resolved NOTHING — no pod matched the selector, the named container is absent, or the matched pod sets neither a container nor a pod-level context — AND the recipe pins no fallback identity. The run parks at phase: Pending on the slow structural cadence rather than being backed up (or restored) as the wrong UID.

Deliberately its OWN condition rather than a reason on SecurityContextInherited: that condition is advisory and carries five unregistered reasons, and registering one of them would make kubectl kopiur doctor classify the other four as “the operator is newer than the plugin” (its first_gate reports a registered condition+status whose reason matches no row as UNREGISTERED). A separate condition keeps the hold visible to doctor and the advisory report advisory. Structural (crate::gates::INHERIT_SOURCE_MISSING_GATE).