fix(strategy): defer checkpoint push only on a truly empty remote

The first cut deferred whenever the push target had no non-metadata branch, which broke checkpoint sync to a remote that already carries entire/checkpoints/v1 but no user branch (the alternates canary seeds exactly this to force a non-fast-forward rebase).

The default-branch hazard #1743 guards against only exists when our push would create the remote's first branch — i.e. a truly empty remote. Once any head exists there, including a checkpoint branch from an earlier push, deferring cannot prevent the default being set and only blocks legitimate syncs. Narrow the guard to fire solely for a target with no refs/heads/*.