Function effective_repository_ref 

pub fn effective_repository_ref(
    snap: &Snapshot,
    policy: &SnapshotPolicySpec,
    policy_ns: &str,
) -> Result<RepositoryRef, ValidationError>

THE repository a policy-child Snapshot runs against, resolved from the mint-time pin + the referenced policy’s repository set. Pure. This is the single decision every launch/deletion/pin/preflight path shares, so multi-repo pin semantics cannot fork between consumers.

The rule, in order:

1. No policyRef — this is NOT a policy child (a SnapshotReplication copy CR, or a discovered row): the policy argument is not this row’s recipe and is ignored; the row’s own derivation (repository_ref_for: status pin → spec pin → owner ref) answers, or [ValidationError::SnapshotRepositoryUnresolvable] when it has none.
2. Pin present (spec.repository) — the pin wins, but it must still be a member of the policy’s CURRENT repository set (compared by normalized repo_key against policy_ns); a pin the recipe no longer lists is the terminal [ValidationError::SnapshotPinNotInPolicy] (“the recipe was edited out from under this Snapshot’s pin”), never a silent re-target.
3. No pin, single-repo policy — the policy’s one spec.repository, verbatim (byte-identical to the pre-multi-repo behavior).
4. No pin, multi-repo policy — [ValidationError::MultiRepoSnapshotUnpinned]: the controller-side backstop of the admission rule; repository #1 is never guessed.

A malformed policy (neither/both repository shapes) surfaces as its [ValidationError::PolicyRepositoryExactlyOne].