repository: Resolve PRs against the upstream repo when available

[huntie]

Summary

Fixes resolution of Pull Requests in ISL, in the case when a Git repo is cloned with both origin and upstream remotes (as is the default for gh repo clone with a user fork of an open source repo).

Example

For a react-native checkout whose origin is huntie/react-native, ISL queries that repo for pull requests that instead live on the upstream react/react-native. It finds nothing, and therefore every pull request stays stuck loading against the wrong repo:

Root cause

getRepoInfo builds codeReviewSystem from paths.default alone, so it always lands on the push remote. The CLI does not: try_find_upstream in the github extension resolves a bare pull request number against paths.upstream before paths.default, and sl pr submit targets get_upstream_owner_and_name(). So the CLI files and reads pull requests upstream while ISL looks for them in the fork — they never agree.

Fix

Resolve codeReviewSystem from an ordered list of candidate repos rather than from paths.default alone: prefer paths.upstream when it names a GitHub repo, and fall back to paths.default otherwise. Leave repos with no upstream untouched — the fallback is then the only candidate.

This is the precedence Sapling's CLI already applies, so ISL and sl pr now resolve a checkout's pull requests to the same repo.

Note: This touches only codeReviewSystem, which feeds the code review provider — pull request queries, review links, and remote file links. Push and pull still use paths.default.

Test Plan

✅ Upstream PRs resolve

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D117880759. (Because this pull request was imported automatically, there will not be any future comments.)