Issues and Pull requests panels resolve to the fork, ignoring gh repo set-default

Describe the feature or problem you'd like to solve

The native TUI panels (Session | Issues | Pull requests | Gists) resolve to
whatever origin points at, with no way to honor a configured base/default
repository. In the near-universal fork-based contribution model this makes the
Issues and Pull requests panels permanently empty.

Concrete layout. A local clone with:

• origin → git@github.com:tykeal/keymaster.git (a fork; issues/PRs
  intentionally disabled/empty)
• upstream → git@github.com:FutureTense/keymaster.git (the real project;
  all issues and PRs live here)

gh already resolves this correctly. In that same directory:

$ gh repo set-default --view
FutureTense/keymaster

But Copilot CLI's own local session store records repository = tykeal/keymaster for every session started in that directory — it never
records FutureTense/keymaster. So the two first-party GitHub terminal tools
disagree about which repository the user is working in, and only gh matches
what the user configured. The direct consequence is that Issues and
Pull requests show nothing, because they are pointed at the fork rather than
upstream.

Environment: GitHub Copilot CLI 1.0.82, Linux x64, github.com.

Observations from inspecting the shipped bundle

These are starting points from reading
~/.cache/copilot/pkg/linux-x64/1.0.82/app.js, offered to save triage time.
They are likely incomplete: the authoritative panel/session repo resolution
appears to run in native code (sessionResolveRepository /
sessionScalarRepositoryName via the native session binding), not in the JS
bundle, so I could not read the definitive precedence.

• There is a hardcoded remote-priority list I8n=["origin","upstream"],
  consumed as
  I8n.map(s=>t.find(a=>a.remoteName===s)).filter(s=>s!==void 0) inside an
  async function BG(e) that calls githubReposFromRemotes(e) and returns
  {headOwner, baseRepos}, debug-tagged [branchPr]. So the branch→PR
  matcher does consider both remotes, ordered origin-first.
• The string gh-resolved does not appear anywhere in app.js. That is the
  git config key gh writes on gh repo set-default
  (remote.<name>.gh-resolved = base). So there is no code path that reads
  gh's configured base repo.

Proposed solution

Copilot CLI and gh are both first-party GitHub terminal tools. A user who has
already told gh which repo is the base (via gh repo set-default) should not
have to tell Copilot CLI separately. gh solved this exact problem with
gh repo set-default and the remote.<name>.gh-resolved git config key;
Copilot CLI should follow the same convention rather than blindly resolving to
origin.

Concrete options, in rough preference order:

1. Read remote.<name>.gh-resolved=base so gh repo set-default just works
   with no extra configuration.
2. Fall back to the GitHub API's parent/source field when origin is a
   fork whose issues are disabled or empty, resolving to the upstream.
3. Offer an explicit setting and/or a panel-level repo switcher so the user can
   pick base vs head per session.

This is the complementary read-side of #2318 ("Ability to default PRs to an
upstream", open, which already proposes gh repo set-default as the
mechanism): #2318 is about which repo PRs are written to, this issue is about
which repo the Issues/PR panels are read from. They may share a single
resolution fix.

Possibly the same root cause ("what is the current repo"): #3927 ("Bare
#NNNNN auto-linkifies against the current repo, breaking cross-repo issue/PR
references", open).

Distinct from #4148 ("Issues panel shows 'No open issues found' on GitHub
Enterprise Server (ghe.com) repos", closed as not planned): that shares the
empty-panel symptom but has a different root cause (enterprise host
resolution), not fork/upstream resolution. This is not a duplicate of it.

Current workaround and why it is unsatisfying

Rename remotes so origin points at upstream and set
git config remote.pushDefault fork. This fights the near-universal fork
convention (tooling, docs, and muscle memory all assume origin is your
fork), and it risks retargeting branch pushes at upstream if pushDefault is
ever forgotten.

Example prompts or workflows

1. In a fork clone, open the Issues panel to review the upstream project's
   open issues without leaving the terminal.
2. In a fork clone, open the Pull requests panel to pick up an open upstream
   PR to review.
3. Reference an upstream issue by bare #1234 in a prompt and have it link to
   the upstream repo, not the fork.
4. Run gh repo set-default FutureTense/keymaster, then start Copilot CLI in
   the same directory and have its panels resolve to FutureTense/keymaster
   automatically.
5. Toggle a session between base (FutureTense/keymaster) and head
   (tykeal/keymaster) to compare open items in the fork vs upstream.

Additional context

Verified before filing: #2318 OPEN, #3927 OPEN, #4148 CLOSED (not planned).
gh repo set-default --view returns FutureTense/keymaster in the clone,
while Copilot CLI's session store records tykeal/keymaster.

Start by reproducing the fork/upstream setup and checking remote.<name>.gh-resolved, then inspect ~/.cache/copilot/pkg/linux-x64/1.0.82/app.js and the native session binding entry points sessionResolveRepository and sessionScalarRepositoryName. Trace how repository is stored for a session and how the Issues and Pull requests panels resolve it. Done means the configured base repository is honored in the panels without changing push behavior.