Function resolve_mover 

pub fn resolve_mover(
    defaults: Option<&MoverDefaults>,
    recipe_sc: Option<&SecurityContext>,
    recipe_psc: Option<&PodSecurityContext>,
    recipe_resources: Option<&ResourceRequirements>,
    recipe_cache: Option<&CacheDefaults>,
    recipe_ttl_seconds_after_finished: Option<i64>,
) -> ResolvedMover

Resolve the effective mover configuration via the layer merge hardened ⊂ moverDefaults ⊂ recipe (ADR-0004 §1/§2).

• defaults: the repository’s moverDefaults (None when the repo sets none).
• recipe_sc/recipe_psc: the recipe’s effective container/pod context, which the controller has already resolved — the explicit mover.securityContext/ podSecurityContext overlaid on top of any context inherited from a workload via inheritSecurityContextFrom (they combine; explicit wins). The full ladder is therefore hardened ⊂ moverDefaults ⊂ inherited ⊂ explicit. Layers merge as (container, pod) pairs via merge_context_pair: field-wise per dimension, plus identity promotion so the effective UID/GID belongs to the highest layer that pins one, regardless of which dimension it wrote — a moverDefaults container-level runAsUser can never shadow an inherited pod-level one. The pair merge is associative, so folding the inner two layers before this call is identical to a flat four-layer merge. The recipe layer enters here as a layer, NOT a whole-chain replacement — the hardened base + moverDefaults still supply drop:[ALL]/seccomp and a partial recipe context can only tighten.
• recipe_resources/recipe_cache: from mover.resources / mover.cache.

node_selector/tolerations/affinity/ttl flow from moverDefaults (no per-recipe surface for the first three today; TTL is overridable by the caller post-resolve).