Verify ancestor walkability on shallow clones in findBaseSha

[RomainCscn]

When findBaseSha checks whether a candidate release's commit is an ancestor of HEAD, it previously gated git merge-base --is-ancestor on commitExists. That gate misfires on shallow CI clones: a side-branch deepening fetch can pull a sibling commit as a boundary parent without extending main's shallow. The object is local but not walkable from HEAD, and merge-base --is-ancestor exits 1 in that case, the same exit code as a genuine non-ancestor, so the candidate is silently rejected.

End-to-end effect: in a main + long-lived release-branch workflow, a sync --release-version=… on main after a release-branch sync would fall through to the empty-range path, skip release creation, and 404 on the next update --stage=….

Fix: replace the commitExists + ensureCommitAvailable + isAncestor with one atomic verifyAncestorReachable that deepens iteratively and only treats a negative as definitive once the repo is fully unshallowed.

Includes a regression test that reproduces the failure inside a real shallow clone.

---

Will also add a new flag in another PR, likely --base-commit or something similar, so that we can allow users to set the base commit explicitly to avoid relying on the ancestor-walk heuristic.

[linear-code]

LIN-70734

[linear-code]

Looks good. The atomic verifyAncestorReachable correctly fixes the false-negative ancestor check on shallow clones, and the regression test verifies the fix with a real shallow clone topology. No blocking issues found.