Count mapping targets as in scope, not just prune candidates

The previous commit read planner.PruneTarget as "refs this request manages". It is not: it answers whether prune could select an ALREADY-UNMANAGED ref, and addPruneCandidates only consults it after skipping the managed set. With Mappings set it therefore reports false for every branch — including the mapping targets themselves.

So the divergence check stopped seeing the one ref a mapping-pinned request most obviously owns. An empty source whose target still held the mapped ref counted zero refs in scope and converged, or reported ErrTargetEmptyUnverified instead of divergence. Converging there means deleting that ref, which is the outcome this whole path exists to refuse, and it is the same mapping case the two preceding commits were meant to fix.

Scope is now planner.TargetScope: a target ref is the request's responsibility if it is a declared mapping target, or if prune could select it. Mapping targets are resolved through validation.ValidateMappings, the same call BuildDesiredRefs uses, so the two cannot disagree about what a mapping names, and short-form mappings match the full ref the target advertises. They are also in scope regardless of exclusions, matching the mapping pass in BuildDesiredRefs, which applies exclusions only to auto-discovery.

PruneTarget's doc now says what it does not answer, since reading it as whole-scope is what went wrong.

The gap was in the tests as much as the code: the mapping cases covered only refs the request does not own, so nothing exercised a target holding the mapped ref. That case, the excluded-but-mapped case, and short-form resolution are all covered now, and all three fail against the previous commit.