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

### 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.

Aucun fichier, test ou point d’entrée n’est indiqué. Commencez par suivre la gestion existante des clics sur les entités GitHub, General settings et les flux « Open in… » ; le travail est terminé lorsque la préférence minimale utile pour les pull requests fonctionne avec la substitution de modificateur demandée, sans modifier les valeurs par défaut existantes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.