Discover PRs when local and tracked remote branch names differ #896

Problem

Session c532f2515bd74c839d510dbe6e57df8a opened and worked on PR #874, but Capacitor never associated the session with the PR. The PR was created at 2026-09-10 20:51:39 UTC and merged at 2026-09-11 15:45:32 UTC. Transcript uploads continued during that period; the PR-session lookup returned [].

The local worktree branch was worktree-eventual-wandering-dusk; the remote PR head was desktop-remote-control-slice2. The session pushed with an explicit refspec:

git push https://github.com/kurrent-io/kcap-cli.git HEAD:refs/heads/desktop-remote-control-slice2

It then fetched that remote branch and configured the local branch to track origin/desktop-remote-control-slice2. The watcher process's --cwd points to the correct worktree.

Reproduction and evidence

Installed GitHub CLI: 2.100.0. Run these commands from the affected worktree:

$ git branch --show-current
worktree-eventual-wandering-dusk

$ git config --get branch.worktree-eventual-wandering-dusk.remote
origin

$ git config --get branch.worktree-eventual-wandering-dusk.merge
refs/heads/desktop-remote-control-slice2

$ git rev-parse --symbolic-full-name '@{push}'
fatal: cannot resolve 'simple' push to a single destination

$ gh pr view --json number,title,url,headRefName
no pull requests found for branch "worktree-eventual-wandering-dusk"

$ gh pr view desktop-remote-control-slice2 --repo kurrent-io/kcap-cli --json number,headRefName
{"headRefName":"desktop-remote-control-slice2","number":874}

The unchanged automatic lookup also returned #874 when run with a process-only push.default=upstream override:

env GIT_CONFIG_COUNT=1 GIT_CONFIG_KEY_0=push.default GIT_CONFIG_VALUE_0=upstream \
  gh pr view --json number,title,url,headRefName

No persistent Git configuration was changed. These comparisons establish a repeatable branch-resolution failure rather than a transient GitHub outage.

Cause

• GitHubPrDetector delegates discovery entirely to argument-free gh pr view.
• GitHub CLI's resolver first resolves the push destination. If that fails, it uses the upstream branch name only for push.default=upstream or tracking; otherwise it falls back to the local branch name. Merely setting the upstream is insufficient here.
• The watcher refreshes every 60 seconds, and PR detection is fresh each time. Repeated attempts nevertheless resolve the same wrong branch.
• The command runner redirects stderr but discards it, returning null for nonzero exits. The watcher log therefore gives no explanation for the missing link.

Suggested fix

Keep the normal lookup first. On a miss, resolve the current branch's configured upstream remote and remote branch, and explicitly query that candidate. Preserve and validate repository/host/head identity: do not combine a branch from another remote or fork with the session's repository, or attach an unrelated PR merely because the session tracks a default branch.

Keep all fallback probes within the existing shared detection budget, continue periodic retries, and leave the user's Git configuration unchanged. Consider bounded diagnostics that distinguish no matching PR from missing CLI, authentication failure, or timeout.

Regression coverage should exercise the real detection seam with differently named local/upstream branches under default push.default, plus normal-lookup success, absent upstream/detached HEAD, cross-repository identity, safe argument handling, and budget exhaustion. Verify that a later successful lookup is emitted as updated repository metadata and creates the session's PR association.