GitSync: deepen/unshallow on update when depth changes (follow-up to #531) #532

Summary

Follow-up to #531. Now that GitSync honors an arbitrary clone depth at clone/obtain() time, the update path could optionally deepen or unshallow an existing checkout when the requested depth differs from what's on disk (mirroring Git.fetch(depth=..., deepen=..., unshallow=...)).

This was split out of #531 because it carries edges and policy questions that warrant their own design, rather than blocking the core clone-depth feature.

Edges to handle

• git fetch --depth N against a full (non-shallow) checkout silently truncates it to a shallow N-commit repo — history loss if applied unconditionally on every update. The update path must not shrink a full repo.
• git fetch --unshallow against a complete repo is a fatal error, so unshallow must be guarded by git rev-parse --is-shallow-repository.
• git exposes whether a repo is shallow but not its current depth, so "depth changed" needs a proxy (commit count / .git/shallow) — define the intended semantics explicitly.

Open questions

• What should depth=None mean for an existing shallow checkout — leave as is, or unshallow?
• Should a numeric depth ever be allowed to shrink a fuller checkout, or only deepen?

Acceptance

• update_repo() honors self.depth on already-cloned repos without history loss on full checkouts.
• Tests cover: shallow→deepen, shallow→unshallow, full→update (no shrink).