feat(github): support enterprise PR indicators

[brianphillips]

Summary

• Enable GitHub pull request indicators for GitHub Enterprise remotes configured through services with the github provider.
• Resolve GitHub service metadata from hosting-service configuration, including distinct git and web domains.
• Use host-specific gh authentication and route Enterprise GraphQL requests to https://<webDomain>/api/graphql while preserving github.com behavior.
• Filter GitHub remote candidates by available authentication before prompting for a base remote, avoiding stale remote.<name>.gh-resolved writes when PR fetching cannot proceed.
• Document GitHub Enterprise setup in the README and config docs.

Testing

• go test ./pkg/gui/controllers/helpers ./pkg/commands/git_commands ./pkg/commands/hosting_service

I also ran go test ./...; it failed in unrelated environment-sensitive style/i18n tests where ANSI colors were disabled and locale auto-detection returned English instead of localized strings.

🤖 Agent Plan

Expand full agent plan

Add GitHub Enterprise Support For PR Indicators

Summary

Extend the existing GitHub PR indicator feature so it works for remotes configured in lazygit's services: map as github:<webDomain>. Keep the behavior opt-in through existing config, reuse gh authentication for the enterprise host, and preserve current GitHub.com behavior.

Key Changes

• Treat a remote as GitHub-capable when its URL matches either default github.com or a configured services entry whose provider is github.
• Resolve GitHub API metadata from the matched service domain:
  • API endpoint: https://api.github.com/graphql for github.com
  • Enterprise endpoint: https://<webDomain>/api/graphql
  • Auth host: <webDomain> passed to auth.TokenForHost
• Refactor GitHubCommands so PR fetching receives host/API information from the matched remote instead of hardcoding github.com and https://api.github.com/graphql.
• Keep existing create/open PR URL behavior unchanged; this change only expands the “show existing PRs next to branches” path.
• Update README/docs to say GitHub Enterprise PR indicators require:
  • gh auth login --hostname <enterprise-host>
  • services: { "<git-domain>": "github:<web-domain>" }

Public Interfaces

• No new user config keys.
• Existing services config becomes meaningful for GitHub PR discovery, not just generated PR/commit URLs.
• Internal interface addition: expose or add a helper in the hosting-service layer that returns matched provider, git domain, web domain, repo owner, and repo name for a remote URL.

Test Plan

• Add unit tests for custom GitHub Enterprise service matching:
  • git@github.example.com:org/repo.git with services.github.example.com = github:github.example.com
  • distinct git/web hosts, e.g. git.example.com = github:ghe.example.com
  • web domain with one port, e.g. github:ghe.example.com:8443
• Add GitHubCommands tests verifying GraphQL endpoint construction for GitHub.com and Enterprise.
• Add auth-host tests verifying TokenForHost receives the enterprise web host, not the default host.
• Add regression tests that non-GitHub providers configured in services do not trigger GitHub PR fetching.
• Run go test ./pkg/commands/hosting_service ./pkg/commands/git_commands ./pkg/gui/controllers/helpers.

Assumptions

• GitHub Enterprise Server exposes GraphQL at https://<webDomain>/api/graphql.
• The existing services: map is the source of truth for custom GitHub Enterprise hosts.
• Users are expected to authenticate with gh for the enterprise hostname before lazygit can fetch PRs.

Review Feedback Follow-up

• Filter GitHub remote candidates by host-specific auth token before base remote selection or prompting.
• Reuse the resolved token when fetching PRs.
• Ensure the base-remote prompt cannot write remote.<name>.gh-resolved for unauthenticated remotes.
• Add helper-level tests covering authenticated filtering and token lookup caching per host.

[brianphillips]

quoting from #5516 (comment) :

my new policy is to no longer accept PRs (especially when it's plainly obvious that they are AI-generated)

@stefanhaller apologies for adding noise to this project. I admit, I did not read your CONTRIBUTING.md before creating the PR. This is my first time looking at the source of lazygit (and golang is not my primary language, professionally) so I fit the criteria you use to describe those who are contributing less than useful PRs. That said, I did read through the diff to try and ensure it was accomplishing what I was needing in a logical manner as best I could.

I'm just a (very grateful) user of lazygit and was attempting to be helpful by proposing something that would fix a gap in functionality for my (almost exclusively) GH enterprise-focused usage of lazygit but I understand if you need to close the PR due to the deluge that AI-coding has resulted in.

Thanks for all your hard work on making this gem of a tool that I have used so much! 🍻