Stricter matching for github.com and ghe.com URLs

[almaleksia]

Summary

GHES hostnames ending on github.com and ghe.com (like mycompanygithub.com) shouldn't be detected as dotcom/ghe hostnames.

Why

Fixes #2000

What changed

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Prompts tested (tool changes only)

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed
• Updated (README / docs / examples)

[Copilot]

Pull request overview

Tightens --gh-host URL classification so GitHub Enterprise Server hostnames that merely end with github.com/ghe.com (but aren’t the real domain or a subdomain) are no longer mis-detected as GitHub.com / GHEC, addressing issue #2000.

Changes:

• Refined dotcom detection to match only github.com or *.github.com.
• Refined GHEC detection to match only ghe.com or *.ghe.com.
• Added unit tests covering suffix vs subdomain cases for both github.com and ghe.com.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
pkg/utils/api.go	Makes hostname matching stricter by requiring exact-domain or subdomain matches for dotcom/GHEC detection.
pkg/utils/api_test.go	Adds coverage for the new matching behavior, including the regression case from #2000.