fix(forge): detect a self-hosted GitLab instead of guessing from its hostname

A self-hosted GitLab whose name is not literally `gitlab.*` — `git.corp.com`, a
bare IP, `gitlab-prod.corp.com` — fell through the hostname heuristic to GitHub,
whose Enterprise API base is `{origin}/api/v3`. GitLab answers every v3 path with
410 "API V3 is no longer supported", so the workbench showed a raw
`forge API error 410` and nothing in the repo panel worked (#611).

The GitLab client was never the problem; only the question of who the host is.
So when no account declares a provider, ask the instance: `GET
{origin}/api/v4/version` exists on GitLab (200 with a token, 401 without) and
404s on GitHub Enterprise.

A JSON 401 alone is not enough — an authenticating gateway in front of a GitHub
Enterprise can answer that to everything, and believing it would break a setup
that works today. A real API also 404s a path it does not route, so the 401 is
confirmed against a nonexistent path. Anything inconclusive falls through to the
hostname guess, leaving unreachable hosts exactly as they were.

Verdicts are cached per host per process, including "answered, not a GitLab" —
`folder_forge_remote_core` runs on every forge call, so an uncached negative
would put a probe in front of each one. Transient statuses (5xx, 408, 429)
record nothing: a 502 from a GitLab mid-deploy must not pin the host to the
guess until restart.

As a backstop, GitLab's 410 is itself an identification. The GitHub client
recognises it, corrects the cache and returns `WrongForge` rather than dumping
the body; the panel silently retries once and the retry lands on the GitLab
client, re-deriving `provider` so the tab wording follows. The user is never
asked to configure anything.