checkpoint_push_remote: election accepts a pushurl-only remote that status then reports as working

strategy.ResolveCheckpointSyncRemote elects a checkpoint_push_remote that names a remote with only a pushurl and no fetch URL, and entire status then reports it as the working destination. Such a remote has no configured fetch destination, so checkpoint reads and reconciliation against it cannot work.

The split is between two existing definitions of "is this a configured remote":

• isConfiguredRemote (strategy/manual_commit_push.go:360) shells out to git remote get-url <name>. For a remote with only remote.<name>.pushurl, git exits 0 and prints the remote name rather than a URL — verified on git 2.50.1 (Apple Git-155): git config remote.pushonly.pushurl https://example.com/x.git && git remote get-url pushonly prints pushonly, exit 0. This is the function the explicit checkpoint_push_remote tier consults, so the fail-closed guard at checkpoint_sync_remote.go:83 passes.
• readRemotesInConfigOrder (checkpoint_sync_remote.go:230) reads remote.*.url via git config --get-regexp, so it correctly omits the same remote. Its own doc comment says so: "Remotes configured with only pushurl are deliberately invisible (spec Unit 1)."

So the automatic tiers exclude a pushurl-only remote and the explicit tier accepts it.

Reproduction, with {"strategy_options": {"checkpoint_push_remote": "pushonly"}} in .entire/settings.local.json and remote.pushonly.pushurl set:

$ entire status
  Checkpoints sync to: pushonly (set by checkpoint_push_remote)

Surfaced by trail 1286, which adds a validateCheckpointPushRemote in the cli package so entire enable refuses to select such a remote. That is the right call for the picker, but it leaves the two commands disagreeing about the same state — the same trail's enable says Cannot confirm checkpoint uploads to pushonly: remote "pushonly" has no configured fetch URL for a remote status presents as fine.

Fixing it properly means making the eligibility rule part of election rather than of setup, which changes behaviour for any existing repo that has this configured: it would move from "elected" to fail-closed, sync disabled until fixed. That is deliberately out of scope for a setup-picker change, hence this issue.

Start with strategy.ResolveCheckpointSyncRemote and compare the explicit checkpoint_push_remote tier in checkpoint_sync_remote.go:83 with isConfiguredRemote in strategy/manual_commit_push.go:360. Review readRemotesInConfigOrder in checkpoint_sync_remote.go:230 and the reproduction involving a pushurl-only remote. Done means election rejects that remote consistently, so entire status does not report it as the working destination.