strategy: don't treat shallow merge-base miss as disconnected metadata

On a shallow checkpoint clone, git merge-base reports "no common ancestor" whenever the real ancestor lives below the shallow boundary — git has no objects there. The disconnection check trusted that exit code as proof of disconnection, so an ordinary diverged-but-behind metadata branch on a shallow clone was misread as disconnected. That triggered a full-history cherry-pick reconcile, which then blew MaxCommitTraversalDepth on a deep team branch and aborted both entire push and entire doctor ("commit chain exceeded 1000 commits without reaching root"), leaving doctor looping on a fix that could never succeed.

checkpoint/v1 clones are routinely shallow (resume/explain fetch the tip with --depth=1 via FetchMetadataTreeOnly and nothing deepens them again), so this hit a normal user who fell behind while out of office.

Fix:

• New metadataDisconnected() only trusts a merge-base miss as a genuine disconnection when the repo is NOT shallow; on a shallow clone the verdict is suppressed and the refs are reported connected. Routed through IsMetadataDisconnected (warn hot path + doctor detection) and ReconcileDisconnectedMetadataRef (push + doctor fix), so the warn path stays network-free and the doomed reconcile no longer fires.
• entire doctor now deepens the metadata branch (--unshallow, best-effort, without advancing the local ref) before the check when the repo is shallow, so it can still detect and repair genuine disconnections on an accurate, fully-materialized history.
• Export remote.IsShallowRepository so both packages share one check.

With the false positive gone, push rebases the local-only commits onto the remote tip normally and doctor reports OK instead of erroring. Genuine empty-orphan disconnections are still caught (by doctor after deepening, and on push the rebase cap still refuses to combine unrelated histories).