artifact: v4+ blocked on self-hosted GHES even on releases that ship the v2 backend (3.13+)

Describe the enhancement

isGhes() in @actions/artifact (packages/artifact/src/internal/shared/config.ts) returns true for any GITHUB_SERVER_URL whose hostname is not github.com, *.ghe.com, or *.localhost. When isGhes() returns true, client.ts throws GHESNotSupportedError on every upload, download, and list call, blocking the v4+ artifact family on every self-hosted GHES instance regardless of release.

GHES 3.13 added the artifact-storage-v2 backend that v4+ clients require. 3.16+ has full production support. Despite that, the hostname-only gate continues to throw on these releases, so v4+ users on supported GHES see:

@actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+
are not currently supported on GHES.

The runtime already exposes a clean signal for whether v2 is reachable: the runner sets ACTIONS_RESULTS_URL exactly when the storage backend is available. The artifact client's own getResultsServiceUrl() (in the same file) already throws if ACTIONS_RESULTS_URL is unset, so it's already a precondition for v4+ paths to function.

Treating its presence as the authority on "is the v2 backend reachable" would unblock GHES 3.13+ without any new env-var contract or operator opt-in.

Code Snippet

Proposed change to packages/artifact/src/internal/shared/config.ts:

const hostnameLooksLikeGhes =
  !isGitHubHost && !isGheHost && !isLocalHost

if (hostnameLooksLikeGhes && process.env['ACTIONS_RESULTS_URL']) {
  return false
}

return hostnameLooksLikeGhes

Additional information

This is narrower in scope than #2123, which takes a more general vendor-aware approach (an explicit ACTIONS_VENDOR env var that operators set to identify their environment, supporting third-party servers like Gitea and Forgejo as well as GHES). That PR addresses the broader compatibility need; this issue covers the specific case of GHES instances on releases that already ship the v2 backend, where the runtime's existing ACTIONS_RESULTS_URL signal lets the action detect v2 availability automatically without operator action.

The two approaches are complementary and could both land. If they do, the check proposed here would short-circuit before vendor detection on v2-supporting GHES.

Start in packages/artifact/src/internal/shared/config.ts by reading isGhes() and getResultsServiceUrl(), then inspect the GHES guard in packages/artifact/src/internal/shared/client.ts. Verify that a self-hosted GHES environment with ACTIONS_RESULTS_URL can use v4+ upload, download, and list calls, while unsupported hosts without that signal remain blocked.