:bug: forge api ignores forge type for base URL

[pigam]

Summary

forge api builds API base URLs from domain-name heuristics instead of the
resolved forge type. This breaks self-hosted instances whenever the domain name
does not contain the substring that forge api expects for that forge.

Reproduction

Given a self-hosted forge with a neutral domain name:

origin git@mylab.example.org:group/project.git

and a config declaring its type:

[mylab.example.org]
type = gitlab

or:

[mylab.example.org]
type = gitea

or:

[mylab.example.org]
type = forgejo

running:

forge api "<endpoint>"

does not reliably use the API root for the configured forge type.

Observed behavior and source

At upstream/main commit b3eb7489772377d24e9687a95f0d5bfdd5027d2d,
internal/cli/api.go chooses the API root by matching substrings in the
domain name.

This produces these built-in behaviors:

• domains containing github get a GitHub-style API root
• domains containing gitlab get /api/v4
• domains containing bitbucket get Bitbucket Cloud's API root
• everything else falls back to /api/v1

Examples:

• a GitLab instance at mylab.example.org is treated as /api/v1 instead of
  /api/v4
• a GitHub Enterprise instance at vcs.example.org would not get the GitHub API
  root
• any self-hosted forge whose hostname does not include the expected substring
  can be routed to the wrong API root

Expected behavior

If the forge type is known from --forge-type, config, or resolution,
forge api should use that type to select the API root, independently of the
domain name.

For example:

[mylab.example.org]
type = gitlab

should imply:

https://mylab.example.org/api/v4

even though the domain does not contain gitlab.

Root cause

The behavior depends on hostname spelling rather than the actual forge type.
The repository/domain resolution already determines or can access the forge
type, but forge api does not use that information when constructing the API
base URL.

The API base URL should be derived in this order:

1. explicit --forge-type
2. configured domain type
3. known-domain defaults
4. legacy domain-name heuristics as a fallback