Reviewing Doctor Remote Fix

I reviewed trail #1303 ("fix(doctor): report a fail-closed checkpoint sync election", head 872a0461, the same commit as this branch). The PR is in good shape. I found no correctness bugs and posted two low-severity findings on the trail.

Findings:

1. The suggested fix command fails in the main case (remote_topology.go:281-283). The doctor note tells the user to run git remote set-url <name> <url>. The usual way to hit this failure is a committed checkpoint_push_remote naming a remote this clone doesn't have. In that case set-url exits 2 with error: No such remote '…' (I tried it in a fresh repo). It only works when the remote exists but has just a push URL, and that's the only case the test at remote_topology_test.go:433 covers. The fix is to suggest git remote add when the remote is missing.
2. The remote name is printed without sanitizing (remote_topology.go:283). misconfigured.Remote comes from settings that can be committed to the repo, and nothing validates it. The other lines that print it use %q, but this one uses %s. So a name containing terminal escape codes reaches the terminal as-is, and a name containing ; or spaces changes the command the user is told to copy. Using tuiutil.SanitizeDisplayText or quoting the name would fix it.

Checked and found fine:

• pinned comes from remote.PushURL, the same check the pre-push hook uses to skip the election, so a remote that has its own dedicated checkpoint_remote URL is exempt in both places.
• entire status now decides on !syncAffected() rather than "any remote is pinned", so it agrees with doctor's PARTIAL report.
• Every caller of printSetupCheckpointDestinationNote runs under entire enable, which also runs report at the end. So suppressing the failed-election note there doesn't leave enable silent about it.
• A new error type (CheckpointPushRemoteNotFetchableError) means the fix advice only appears for a bad remote name, not for an unreadable settings file.
• The hook-environment fix in isConfiguredRemote is correct.

The trail is marked as conflicting with main and 137 commits behind, so it needs a merge or rebase before it can land.

The conflicts are resolved and both packages pass. Committing the merge, then running the full mise run check and the complexity gate that main added.