[Bug]: Thread shows the base branch's PR when the branch tracks a non-default base

[AyushKaithwas]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use a repository whose GitHub default branch is main but which integrates through a second branch: feature branches are cut from dev, and dev reaches main through release PRs. gh pr list --head dev --state all therefore returns a list of merged dev -> main PRs.
2. git checkout -b feature/x origin/dev, so branch.feature/x.merge is refs/heads/dev. Plain git and T3's own base-branch flows both leave a branch tracking the ref it was cut from.
3. Open a thread on that checkout and leave the branch unpushed, so it has no change request of its own.

Expected behavior

No PR badge. The branch has no pull request.

Actual behavior

The thread row and the composer footer show the newest merged dev -> main release PR (#49 in my case), which has nothing to do with the thread. Every thread on that checkout shows the same number, and it moves to whatever the next release PR is.

prLookupCache in apps/server/src/git/GitManager.ts derives the head selector from the upstream ref, so the lookup asks for --head dev. The guard right below it only suppresses that when the upstream is the repository default branch (main or master), so a non-default base falls through, and findLatestPrForHeadContext returns the most recently updated PR when none is open. Because that PR is merged, the client then keeps it across checkouts (retainTerminalOnBranchMismatch in ThreadStatusIndicators.tsx), and a merged PR also settles the thread.

Impact

Major degradation or frequent failure

Version or commit

0.0.34-nightly.20260825.1183, also present on main @ e67074f

Environment

macOS (Darwin 25.2.0), desktop nightly, GitHub through gh

Workaround

git push -u origin HEAD so the upstream carries the branch's own name, or git branch --unset-upstream.