git_operations: stop shallow-fetching the metadata tip

FetchMetadataTreeOnly resolves the latest checkpoint on resume / explain / attach. It fetched with --depth=1, which adds the fetched tip to .git/shallow. Once the entire/checkpoints/v1 tip is a shallow boundary, a later git merge-base against refs/remotes/origin/entire/checkpoints/v1 can no longer reach the real common ancestor (it lives below the boundary), so the disconnection check falsely reports "no common ancestor" — aborting git push and looping entire doctor. This is the upstream source of the shallow-metadata false-disconnect: it is self-inflicted by the CLI's own tip-read on essentially every resume when checkpoints live on origin (no checkpoint_remote short-circuit).

The shallow boundary is intrinsic to --depth=1 — the fetched commit is truncated regardless of which ref it lands on, and git opportunistically points refs/remotes/origin/<branch> at it anyway. So the fix is to not shallow at all: fetch the metadata commit+tree graph at full depth and rely on --filter=blob:none (when filtered fetches are enabled) to skip blob content. git fetches incrementally, so after the first fetch only new commits/trees travel. The remote-tracking ref stays connected and merge-base works.