Also refresh branches and remotes when refreshing pull requests

The pull-request fetch queries GitHub for the tracking branches'
upstreams against the configured remotes. It therefore depends on the
branches and remotes being up to date; a refresh that asks for pull
requests but not for those (e.g. checking out a branch) would fetch
against a stale branch/remote list — for instance missing the PR of the
branch just checked out.

Expand the scope so pull requests always co-refresh branches and
remotes. This also sets up the next commit to hand the freshly-loaded
branches and remotes straight to the fetch, instead of reading them
back from the model (which, now that those writes are bounced onto the
UI thread, would be stale on the worker).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

pkg/gui/controllers/helpers/refresh_helper.go

@@ -131,6 +131,8 @@ func (self *RefreshHelper) Refresh(options types.RefreshOptions) {
 		//     can move HEAD), so refresh commits + branches alongside
 		//   - submodules are refreshed as part of the files refresh
 		//   - merge conflicts are part of what the files refresh produces
+		//   - pull requests are fetched for the tracking branches against the
+		//     remotes, so refresh both alongside to fetch against fresh data
 		if scopeSet.Includes(types.REFLOG) || scopeSet.Includes(types.BISECT_INFO) {
 			scopeSet.Add(types.COMMITS, types.BRANCHES)
 		}
@@ -140,6 +142,9 @@ func (self *RefreshHelper) Refresh(options types.RefreshOptions) {
 		if scopeSet.Includes(types.FILES) {
 			scopeSet.Add(types.MERGE_CONFLICTS)
 		}
+		if scopeSet.Includes(types.PULL_REQUESTS) {
+			scopeSet.Add(types.BRANCHES, types.REMOTES)
+		}
 
 		// Capture the refs snapshot now, before we start reading git's state
 		// below, rather than after. This is important to guard against the race