Function validate_repository_seed 

pub fn validate_repository_seed(
    seed: Option<&SeedSpec>,
    repo_backend: &Backend,
    mode: RepositoryMode,
    create: Option<&CreateBehavior>,
    kind: RepositoryKind,
) -> Vec<ValidationError>

Validate spec.seed on a Repository/ClusterRepository, accumulating every independent problem.

Everything here is derivable from the spec alone, so both aggregate validators call it and the controller gets it for free on its defensive re-validation. Two seed rules are NOT derivable and live beside it as separately-callable helpers the webhook invokes with the request’s context: validate_seed_secret_namespace (the namespaced arm of the co-resident Secret rule) and validate_seed_not_self (migrate-mode self-reference).

The rules, and why each exists:

• A seed runs in a mover Job, so neither the repository nor a filesystem seed source may be a bare path — nothing would be mounted at it.
• mode: ReadOnly and seeding are contradictory.
• A mode-specific tuning block (sync/migrate/credentialProjection) paired with the other mode’s source would be inert.
• Blob mode inherits the mirror’s repository format, so explicit create.{splitter,hash,encryption,ecc} would be inert too.
• Blob mode must not read its own storage, must not collide on an in-pod mount path, and must not mix workload identity with static keys in the one seeding pod (the same three rules a RepositoryReplication gets, for the same reason: one pod, two backends).
• A ClusterRepository’s seed-source Secret must not pin a namespace — a cluster-scoped repository resolves credentials in the operator namespace, which the spec cannot name.