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

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 @ 35172010b1

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.

Start in apps/server by tracing how the repository remote is parsed before the pull-request pane invokes GitHub CLI. Reproduce the SSH alias with the provided ssh and gh commands, then verify that the API/browser host resolves to github.com while the SSH alias remains available for authentication. Done means pull requests load in the pane for repositories using SSH aliases without breaking ordinary or self-hosted hosts.