strategy: stop resolvePushSettings tests from fetching github.com

[Soph]

https://entire.io/gh/entireio/cli/trails/605

Why

Three TestResolvePushSettings_* tests in checkpoint_remote_test.go were doing a real network fetch against github.com, which blocks on a macOS keychain prompt and is slow/flaky in CI.

Each test configures a checkpoint_remote of {github, org/checkpoints} and calls resolvePushSettings, but never creates a local entire/checkpoints/v1 branch. resolvePushSettings → fetchMetadataBranchIfMissing then runs a live git fetch against the resolved checkpoint URL (https://github.com/org/checkpoints.git / its SSH form). GitHub returns 401 Basic realm="GitHub", git invokes its osxkeychain credential helper, and the run stalls on a keychain access prompt.

Found while reviewing #1454 — this is a pre-existing bug on main, unrelated to that PR and unrelated to the token-store isolation in #1450 (this is git's own credential helper, a different subsystem).

What changed

Seed the local entire/checkpoints/v1 branch in the three affected tests (via the existing runCheckpointRemoteGit helper) so fetchMetadataBranchIfMissing finds it and short-circuits before fetching. The pushTarget() / hasCheckpointURL() assertions are unaffected — checkpointURL is resolved before the fetch.

The two owner-mismatch tests (ForkDetection, FetchURL_IgnoresOwnerMismatchCheck) already return before the fetch, so they're left untouched.

Verification

• Re-ran the three tests with credential.helper forced to a logging shim: 0 credential-helper calls (was 2× host=github.com).
• Each test now runs in ~0.03s (previously multi-second network timeouts).
• mise run fmt + mise run lint clean (0 issues).

🤖 Generated with Claude Code

---

Note

Low Risk
Test-only setup changes with no production code paths modified.

Overview
Three TestResolvePushSettings_* cases in checkpoint_remote_test.go now create a local entire/checkpoints/v1 branch (via runCheckpointRemoteGit) before calling resolvePushSettings.

That matches production behavior when metadata is already present and stops fetchMetadataBranchIfMissing from issuing a real git fetch to the derived github.com checkpoint URL—avoiding slow/flaky CI runs and macOS keychain credential prompts on 401. Assertions on pushTarget() and hasCheckpointURL() are unchanged because URL resolution happens before the fetch.

^{Reviewed by Cursor Bugbot for commit 8767fe1. Configure here.}

[Copilot]

Pull request overview

This PR prevents three resolvePushSettings unit tests from performing a real git fetch to github.com by ensuring the local metadata branch (entire/checkpoints/v1) exists during test setup, avoiding slow/flaky network behavior and macOS credential-helper prompts.

Changes:

• Seed entire/checkpoints/v1 locally in the three affected TestResolvePushSettings_* cases using the existing runCheckpointRemoteGit helper.
• Add explanatory comments documenting why the metadata branch is created in these tests (to short-circuit fetchMetadataBranchIfMissing).