[Bug]: Pull request pane treats SSH aliases as GitHub API hosts

[jdlar1]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Configure a GitHub SSH alias:

   Host github-personal
     HostName github.com
     User git
     IdentityFile ~/.ssh/id_ed25519_personal

2. Use that alias in a repository remote:

   git@github-personal:OWNER/REPOSITORY.git
   

3. Open the repository in T3 Code on a branch with an open pull request.

4. Click the pull-request indicator from the thread view.

5. Observe the new in-app pull-request pane.

Expected behavior

The pane should use github.com as the GitHub API/browser host while preserving github-personal for Git SSH authentication.

Actual behavior

T3 derives the repository's canonical host directly from the remote and records github-personal as a self-hosted GitHub hostname. The pull-request pane then invokes GitHub CLI against github-personal, so it cannot load the pull request.

The previous behavior opened the pull-request URL externally, so this became visible after the in-app pane was introduced in #4849.

Impact

Major degradation or frequent failure

The pull-request pane is unavailable for every repository using the common SSH-alias pattern for multiple GitHub accounts.

Version or commit

main @ 3517201

Environment

Linux 7.0.0-29-generic x86_64
gh 2.97.0
OpenSSH 10.2p1
Affects the web UI and desktop wrapper

Logs or stack traces

$ ssh -G github-personal 2>/dev/null | awk '$1 == "hostname" { print $2; exit }'
github.com

$ gh repo view github-personal/pingdotgg/t3code --json nameWithOwner --jq '.nameWithOwner'
error connecting to github-personal

$ gh repo view github.com/pingdotgg/t3code --json nameWithOwner --jq '.nameWithOwner'
pingdotgg/t3code

Workaround

Open the pull request manually in the browser. Changing the remote to use github.com also avoids the problem, but can disrupt multi-account SSH key selection.

Implementation

I’d be happy to prepare a focused PR after maintainers confirm the preferred normalization boundary.