refactor(strategy): replace empty-remote network probe with a local, git-branch-only guard

Implements pjbgf's CHANGES_REQUESTED review (#1744):

• Gate by checkpoint type: git-refs stores checkpoints under refs/entire/*, which a forge cannot select as a default branch, so the first-user-branch guard is git-branch only. prePush now returns via prePushCheckpointRefs for git-refs without ever consulting the guard.
• Decide locally, no network: deferCheckpointPushOnEmptyRemote now checks only for a local remote-tracking ref (refs/remotes/<remote>/*) via git for-each-ref. Git records one after the first successful push, so deferred metadata publishes on the next push. Removes the ls-remote probe entirely — a network round trip on pre-push can trigger an SSH security-key touch prompt, and per-push-URL probing multiplied those prompts.
• Use only the remote git handed the hook: dropped PushTargetsInDir / get-url --push --all (and its multi-pushurl handling). Different push URLs can need different auth (unexpected Yubikey flashing).

This deletes the whole probe/marker apparatus from the prior rounds — marker file, TTL, fingerprint, os.Root storage, probe timeout, disable-time sweep, and the PushTargetsInDir helper — since a local ref check needs no memoization. The io.LimitReader review note is moot (the marker read is gone).

Note: HEAD-specifically (refs/remotes/<remote>/HEAD) isn't created by push (verified), so it would defer forever in the init+push flow; any tracking ref is the robust signal. The multi-pushurl-empty edge (Copilot's note) is intentionally no longer handled, per the auth/UX tradeoff above.

Tests: unit test proves the guard is local-only (unreachable URL, never dialed); integration test now asserts both behaviors — git-branch defers then publishes, git-refs publishes on the first push. Alternates canary records a tracking ref to reflect an established remote. Full canary 59/59.