feat(github): add GitHub Enterprise Server support to GitHub Action

[balcsida]

What does this PR do?

Fixes #12830

The GitHub Action hardcodes github.com URLs everywhere, so it can't run on GHES. This PR reads GITHUB_SERVER_URL and GITHUB_API_URL env vars (set automatically by GHES runners) and uses them to derive all host-specific values — Octokit/GraphQL baseUrl, git credential config keys, noreply emails, fork remote URLs, image attachment regexes, and the token revocation endpoint. Defaults to github.com when the env vars aren't set, so nothing changes for existing users.

Also adds a parseGitRemote function (host-agnostic version of parseGitHubRemote) so the install command detects GHES remotes and generates a workflow with use_github_token: true and write permissions pre-configured.

How did you verify your code works?

• Both files transpile cleanly with bun build --no-bundle
• All 38 existing + new tests pass (bun test test/cli/github-remote.test.ts and github-action.test.ts)
• New tests cover parseGitRemote with GHES URLs, SSH, HTTPS, various hosts
• Verified no remaining hardcoded github.com references that should be parameterized (only defaults, comments, and the opencode app URL which correctly stays on github.com)

[neronlux]

Great request to allow use in Enterprise

[entl]

Are there any plans to merge this feature? It would be very helpful for GitHub Enterprise Server users.

[rover0811]

Thanks for working on GHES support. I reproduced the current failure with OpenCode 1.18.9 and the pinned official GitHub Action on a GHES runner. The runner provides an internal GITHUB_API_URL, but github.handler.ts constructs Octokit without a baseUrl, so the GHES token is sent to api.github.com and the run fails with 401 Bad credentials.

This PR addresses that REST failure, but I noticed the GraphQL client currently receives ghUrls.apiUrl as its baseUrl. On GHES, GITHUB_API_URL normally ends in /api/v3. @octokit/graphql appends /graphql and documents the GHES baseUrl as https://host/api, so using the REST URL would target /api/v3/graphql instead of the GHES endpoint /api/graphql. GitHub Actions also provides GITHUB_GRAPHQL_URL.

Could getGitHubURLs return a separate GraphQL base URL, using GITHUB_GRAPHQL_URL with the trailing /graphql removed, and fall back to serverUrl + /api for GHES? A focused request-mocking test that asserts the final REST and GraphQL URLs would also catch this distinction.

I can validate an updated branch against the GHES dry-run that exposed the 401. I have omitted the private host and credentials from this report.