[Feature]: GitHub Enterprise support in the source control connector

[JorrinKievit]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Problem or use case

The GitHub connector only recognizes github.com. On a GitHub Enterprise host — GHES on an arbitrary hostname, or GHEC data residency on <tenant>.ghe.com — the provider is never detected, so PR listing, PR creation, publish, and clone all fall back to the generic "unknown" path even when gh is already authenticated against that host.

Concretely, with two authenticated hosts:

$ gh auth status --json hosts
{"hosts":{"github.com":[{"state":"success","login":"…"}],
          "acme.ghe.com":[{"state":"success","login":"…"}]}}

Only github.com shows up in Source Control settings. The enterprise host is invisible to the app despite gh being able to talk to it.

Two related details that make this more than a labeling problem:

• detectSourceControlProviderFromRemoteUrl classifies arbitrary GHES hostnames as unknown, so nothing downstream routes to the GitHub provider.
• Repo-less gh operations (repo view owner/repo, repo create) have no remote to infer a host from, so they need GH_HOST to target an enterprise host at all.

Proposed solution

Treat GitHub Enterprise as a separate provider kind alongside github, with hosts derived from gh auth status so there is nothing new to configure. I went with the Cursor design where they are seperate connectors, and you can have multiple instances of GitHub Enterprise configured.

The piece that seemed worth getting right: a user can be authenticated against several enterprise hosts at once, so one gh discovery probe needs to emit one row per authenticated host rather than one row per provider kind. GitLab's existing refineUnknownRemote hook already covers the "claim an unclassifiable hostname" half of this.

Alternatives considered

Making github accept an optional host instead of adding a kind. That works for a single enterprise host but collapses when someone is authenticated against github.com and two enterprise hosts simultaneously, since discovery rows and settings entries are keyed by kind.

Risks or tradeoffs

• Reclassification: a github.acme.com remote currently classifies as kind github. Moving it to an enterprise kind changes anything gated on kind === "github"

[DominicVonk]

#6052 Opened a PR for full multi-GitHub accounts, including enterprise