Curate the error when the sync target is checked out in another worktree - #14076

Follow-up to #14060, which fixes #12927. Targets 12927-fix-repo-sync-worktree so @sergiou87 can take it or leave it.

Description

A git repository can have more than one working directory attached to it, via git worktree. Each one has its own checked-out branch, its own index, and its own files on disk, but they all share one set of branch refs.

gh repo sync updates your local branch to match the remote. When the branch you're syncing isn't the one you currently have checked out, it can't merge into your working directory, so it moves the branch ref directly instead. #12927 reported that this silently corrupts things: if some other worktree has that branch checked out, moving the ref leaves that worktree's index and files pointing at the old commit, so everything shows up as staged changes.

#14060 fixes that by switching from git update-ref to git branch --force. Git itself refuses to move a branch another worktree is using, so silent corruption becomes a hard failure. That's the right call. The gap is what the user sees:

failed to run git: fatal: cannot force update the branch 'main' used by worktree at '/path/to/worktree'

That's a raw git error with a doubled failed to run git: fatal: prefix. It's also inconsistent with what gh repo sync does six lines away in the same function, where a dirty working directory produces a curated message and a tip:

refusing to sync due to uncommitted/untracked local changes
tip: use `git stash --all` before retrying the sync and run `git stash pop` afterwards

This PR detects the worktree case before attempting the update and gives it the same treatment:

can't sync "main" because it's checked out in another worktree at /path/to/worktree
tip: run `gh repo sync` from that worktree instead

Detection runs git worktree list --porcelain and looks for a worktree holding refs/heads/<branch>. git branch --force stays in place as the safety net.

How did you test this change?

$ GH_ACCEPTANCE_SCRIPT=repo-sync-worktree.txtar GH_ACCEPTANCE_HOST=github.com \
  GH_ACCEPTANCE_ORG=gh-acceptance-testing GH_ACCEPTANCE_TOKEN=$(gh auth token) \
  go test -tags=acceptance -run ^TestRepo$ ./acceptance -v

# Syncing from the linked worktree must refuse rather than silently move the default branch ref (1.287s)
> cd ../topic-worktree
> ! exec gh repo sync
[stderr]
can't sync "main" because it's checked out in another worktree at $WORK/repo_sync_worktree-SBHtlzxkHD
tip: run `gh repo sync` from that worktree instead
[exit status 1]
> stderr 'can''t sync "main" because it''s checked out in another worktree at .*'$SCRIPT_NAME'-'$RANDOM_STRING'$'
> stderr 'tip: run `gh repo sync` from that worktree instead'
# The primary worktree's branch and working tree are left untouched (0.025s)
> exec git status --porcelain
> ! stdout .
> ! exists asset.txt
# Syncing from the primary worktree, where the default branch is actually checked out, still works (1.308s)
> exec gh repo sync
> exists asset.txt
PASS

--- PASS: TestRepo/repo-sync-worktree (8.73s)

I also ran that acceptance test against trunk to confirm it's a real regression test and not just a test that agrees with the new code. It fails there, because update-ref silently succeeds:

> ! exec gh repo sync
FAIL: testdata/repo/repo-sync-worktree.txtar:28: unexpected command success

Key points

We use the porcelain output to avoid matching on the git error message which I believe version and locale dependent. This does introduce a small potential race, but it seems like a reasonable first step.

Notes for reviewers

None

Authorship and follow-up

Who wrote this:

• A human wrote it.
• An agent wrote it under close human direction.
• An agent wrote it independently, and no human has guided the implementation beyond the initial prompt.

Who answers review comments:

• @williammartin will read and reply directly.
• An agent will draft replies and @username will read them before they are posted.
• Nobody has explicitly committed to replying.