Let me choose where clicking a pull request or issue opens: in-app session vs browser

[titan-ron]

Feature summary

Add a configurable "open behavior" per GitHub entity type (pull request, issue, repo, commit, …) so clicking a PR can open an in-app session, the built-in browser, or my default external browser — my choice, not a fixed one.

What problem are you trying to solve?

Today, clicking a pull request in My Work / the sidebar always does the same thing. There is no way to say "pull requests should open on github.com in my browser, but issues should open here as a session".

That matters because the two targets are genuinely good at different things:

• The in-app PR session is what I want when I intend to work on the PR — check out the branch, read the diff with an agent, push fixes.
• github.com in my real browser is what I want when I intend to review or discuss — full review UI, checks, required reviewers, projects, my extensions, and my already-signed-in session with its cookies and settings.

Other AI-native IDEs let me pick this per link type, and I keep reaching for a modifier key out of habit and getting the wrong surface. The workaround is copying the URL and pasting it into a browser manually, which defeats the point of having My Work in the app.

This is the same class of gap as #2295, but that request is only about links in general. The click target for GitHub entities is the part that bites daily.

Proposed solution

1. A per-entity "Open behavior" preference

Settings → General → Open behavior, one row per entity type, each with the same options:

Entity	Options
Pull request	Ask · In app · Built-in browser · External browser
Issue	same
Repository	same
Commit	same
Discussion	same
Review comment	same
Notification	same

Defaults stay exactly as they are today, so nothing changes for anyone who does not touch the setting.

2. Modifier-click override that does not mutate the setting

• Cmd/Ctrl + click → open in the other target (whatever the configured default is not).
• Shift + click → always the external browser.

This gives a fast escape hatch without a trip to settings.

3. Context menu on every clickable GitHub row

Right-click a PR/issue row → Open in app · Open in built-in browser · Open in default browser · Copy link. Discoverable, and it works even if someone never finds the setting.

4. Ask mode with a learn-once affordance

When the preference is Ask, show a small chooser with a "Remember this for pull requests" checkbox that writes the setting. That way the preference can be discovered in the flow rather than hunted for.

Workflow impact

Anyone using My Work as their entry point for review, which is most people using the app for more than one repo. It removes a repeated "wrong surface → go back → copy URL → paste in browser" loop, and it lets people who prefer github.com for review keep the app as their work queue instead of abandoning My Work entirely.

It also composes well with the existing "Open in…" work: #1080 and #2149 are about curating and renaming external open targets, and this request is about which target a GitHub entity click resolves to. The two together would make open behavior fully predictable.

Installation context

Desktop app, local and cloud sessions, any install scope.

Additional context

Related: #2295 (setting to open links in external browser), #1080 (curate the "Open in" list), #2149 (rename custom "Open in" entries).

Smallest useful first step, if the full matrix is too much: just a single "Pull requests open in" preference with In app / External browser, plus the modifier-click override. That alone would cover the majority of the pain.