fix(tasks): resolve PR work items upstream-first under 'auto' like issues

[moseoh]

Summary

Related to #8726 (item A).

On a fork (origin = fork, upstream = canonical repo), opening Tasks → PRs with no explicit source preference shows "No matching GitHub work" even though the user's PRs exist upstream — while the source selector highlights Upstream.

Under auto, the issue side resolves upstream-first, but resolvePrWorkItemSource pinned the PR side to origin — the fork's own PR list, which is almost always empty, since fork-contribution PRs live on the upstream repo. So the PRs tab was empty by default on exactly the repos where upstream/origin routing matters, and the highlighted pill (which reflects the issue-side heuristic) contradicted where the PR data actually came from.

#5166/#5176 fixed explicit picks (both sides follow an explicit Upstream/Origin selection) but consciously deferred the auto side. This PR aligns it — one resolution expression in resolvePrWorkItemSource, shared by listWorkItems and countWorkItems, so the list, pagination totals, and sources.prs metadata stay consistent:

issueSourcePreference	Issues (unchanged)	PRs before	PRs after
'upstream' (explicit)	upstream ?? origin	upstream ?? origin	upstream ?? origin
'origin' (explicit)	origin	origin	origin
'auto' / unset	upstream ?? origin	origin	upstream ?? origin

Repos without an upstream remote are unaffected: upstreamCandidate is null, so the ?? origin fallback preserves today's behavior. A side benefit: when auto collapses both sides onto the same repo, the default count uses one search call instead of two.

Repro (before): fork with origin + upstream remotes, never touch the source selector → Tasks → PRs → empty list with the Upstream pill highlighted; clicking Upstream (which writes the explicit preference) suddenly populates it.

Screenshots

Before (auto, PRs tab)	After (auto, PRs tab)

Testing

• pnpm lint
• pnpm typecheck
• pnpm test — 2 new regression tests (written first, red on the old resolver): (1) auto + upstream remote → the PR list queries upstream and sources.prs reports it; (2) the default count collapses to one search call when both sides resolve to upstream. Full src/main/github (375 tests) and the consuming renderer suites (389 tests) pass.
• pnpm build
• Verified in the dev app on this repo's fork setup: PRs tab populates under auto (was empty), explicit Origin still pins to the fork, Issues tab unchanged.

AI Review Report

• Consistency sweep — resolvePrWorkItemSource has exactly two callers (listWorkItems, countWorkItems); both inherit the change, so lists and pagination totals cannot diverge. The raw originCandidate/upstreamCandidate metadata is untouched, so the selector's render gate (raw-candidate divergence, per Route task PR queries by upstream source #5176's design) is unaffected.
• Renderer impact — under auto on a fork, sources.issues === sources.prs now, so the "Issues from X" indicator chip correctly stops rendering (there is no split to announce). Selector, TaskPage source-state, and store cache suites pass unchanged.
• Explicit preferences — 'origin' and 'upstream' branches are behaviorally identical to before; 'upstream' with a missing upstream remote still falls back to origin.
• SSH/WSL — resolution flows through the same connectionId/localGitOptions plumbing; no new lookups (the upstream probe was already made for upstreamCandidate).
• GitLab / other providers — untouched; notably GitLab MR lists already route through the issue-source resolver (upstream-first under auto — listMergeRequests in gitlab/client.ts), so this change also removes a GitHub↔GitLab inconsistency in how auto treats the PR/MR side.

Security Audit

No new inputs, IPC, command execution, or dependencies — one resolution expression in the main-process GitHub client plus tests.

Notes

• Route task PR queries by upstream source #5176's (since-removed) design doc deferred the auto side as out of scope at the time; this completes that deferred half. The practical argument: a fork's own PR list is nearly always empty, so the old default rendered the PRs tab useless on forks.
• Deliberately Related to (not Fixes) [Bug]: Tasks upstream/origin problems on forks — auto PR routing, stale source switches, slow page jumps #8726 — that issue tracks the whole cluster; this addresses item A only. Item B (stale lists when toggling without a manual refresh) reproduces on main before and after this change and is under separate investigation.
• PR detail lookups still resolve preference-blind — that is [Bug]: PR details fail to load for fork repositories — getOwnerRepo only checks origin #7331/Load PR details in forked repositories #7513 territory and not touched here.

[coderabbitai]

📝 Walkthrough

Walkthrough

Automatic pull request source resolution now prefers the upstream repository for non-origin preferences, falling back to the origin repository when needed. Tests cover upstream PR retrieval and source metadata for listWorkItems, along with collapsed upstream search counting for countWorkItems.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main behavior change: auto PR resolution now prefers upstream like issues.
Description check	✅ Passed	The description follows the template with all required sections and concrete testing, review, security, and notes details.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}