suggestion: this condition keeps repeating in multiple places. Would there be any value in refactoring it to a function?

I think it's used in 2 places like that and 1 other place negated, so it could be turned into a function. The question is would a function called something like isDotComOrGHEC() (please give me a better name) provide as much clarity as seeing the code above? I was thinking that from a Go perspective this would be premature drying, but after writing my replay I'm leaning more towards the function approach. Especially as I could then add some tests.

I'd go with the rule of 3 (3 or more implementations to trigger an abstraction) on this one given the logic is not significantly complex and abstraction feels like an over correction.

If you are going to abstract it I'd suggest getting rid of the negation (nots in sequence always tend to make things harder to reason IMO - though I might be alone on that 😉 ). Something like:

func isGitHubHosted(hostname string) bool {
    return hostname == DotComHost || GHECDataResidencyHostMatch.MatchString(hostname)
}

then

if !isGitHubHosted(hostname) {
   // Add the prefix or segment
}

I'd go with the rule of 3 (3 or more implementations to trigger an abstraction) on this one given the logic is not significantly complex and abstraction feels like an over correction.

If you are going to abstract it I'd suggest getting rid of the negation (nots in sequence always tend to make things harder to reason IMO - though I might be alone on that 😉 ). Something like:

func isGitHubHosted(hostname string) bool {
    return hostname == DotComHost || GHECDataResidencyHostMatch.MatchString(hostname)
}

then

if !isGitHubHosted(hostname) {
   // Add the prefix or segment
}