fix(doctor): address trail 1303 findings

Six findings on trail 1303, all real. Two High ones were answered by the merge to main and the rest are fixed here.

01M51C58XGBQ + 01M27Y4FT6XR (High): main elects only remotes with a fetch URL since #2370, so this branch's git remote get-url probe would have reintroduced the pushurl-only bug. The merge took main's check; this drops the apparatus that existed only to serve the old one — git_remote_cache.go is identical to main again and configuredRemote is gone, which also makes the loop-logic finding moot. One line is kept deliberately: EnvWithoutRepoOverrides() on a probe that sets cmd.Dir and runs inside pre-push, which main is missing and the git-safety rule requires.

01M51C5J7D7E (Medium): computeCheckpointSyncInfo keyed the dedicated-destination claim on "any remote is pinned", so a repo with a pinned origin and an unpinned fork had status claim a clean dedicated destination and drop the error while doctor reported PARTIAL. Gated on !syncAffected() instead, so the claim holds only when no remote is left unpinned.

01M51C5QZX42 (Low): enableCheckpointRemoteChoice.report already names a failed election and offers entire enable --checkpoint-push-remote <name>, so the new note printed the condition twice with two different fixes. The report is doctor-only now and enable's headers carry ambiguity alone.

01M51C5N89PT (Medium): "is not one of this repo's remotes" is false for a pushurl-only remote, which git remote lists. Now "missing or has no fetch URL", with git remote set-url among the remedies.

01M51C5T8M01 (Low): with push_sessions=false nothing is pushed anywhere regardless, so "pushes carry no session history" blamed the wrong setting. The note says pushing is off and frames the election failure as what a push would meet once re-enabled.

Four regression tests, each mutation-checked: removing the fix fails the test.