fix(config): use host key only as a fallback

Description

If your glab config file has host: gitlab.example.com, glab stops working in any repository whose remotes are on a different GitLab host. This MR fixes that.

The config host is now a preference, not a filter. When a remote matches it, glab still uses that remote. When none matches, glab picks a remote the same way it does when no host is set.

The environment variables (GITLAB_HOST, GL_HOST, GITLAB_URI) still act as a strict filter and still fail when nothing matches. That behavior is documented and intended, so I kept it. I believe only the config file key became a filter by accident, in a 2022 refactor. When the error happens, it now names the variable that is really set, so GL_HOST users no longer see GITLAB_HOST in the message.

One thing changes for users who only set the config host: inside a repository, glab now treats the remote's host as the default. So -R OWNER/REPO, glab auth status, glab repo clone and non-interactive glab auth login go to the remote's host. Users without a config host already get this today.

Related Issues

Closes #8595

How has this been tested?

I reproduced the issue by hand with a glab binary built from main and one built from this branch. I used an empty repository with a gitlab.com remote and a temporary config directory with host: gitlab.tuwien.ac.at:

$ git remote -v
origin	https://gitlab.com/gitlab-org/cli.git (fetch)
$ cat "$GLAB_CONFIG_DIR/config.yml"
host: gitlab.tuwien.ac.at

Built from main, it fails:

$ glab issue view 8595
   ERROR
  Could not determine base repository: none of the git remotes configured for this repository correspond to the
  GITLAB_HOST environment variable. Try adding a matching remote or unsetting the variable.
  GITLAB_HOST is currently set to gitlab.tuwien.ac.at

Built from this branch, it uses the gitlab.com remote:

$ glab issue view 8595
title:	`host` config key / GITLAB_HOST overrides repo remotes instead of acting as a fallback
state:	open
author:	ziegenberg

Then I emptied the config file and set GITLAB_HOST=gitlab.tuwien.ac.at instead. The branch build still fails with the same error, as intended.

I also added unit tests for the config case, the environment variable case and the GL_HOST error message. To make sure they catch the bug, I put the old behavior back in a scratch copy, and the new tests failed there. The existing factory tests used to read the remotes of whatever checkout they ran in, so I made them use a temporary repository.

Checks I ran locally on the changed package:

$ go test -count=1 ./internal/cmdutils/
ok  	gitlab.com/gitlab-org/cli/internal/cmdutils	2.243s
$ golangci-lint run --new-from-rev=upstream/main ./internal/cmdutils/
0 issues.

gofmt and go vet printed nothing. I didn't run make test, make lint or the integration tests locally, so I'm relying on the pipeline for those.

This MR might conflict a little with !3896, which also edits the same factory file.

Implemented with AI assistance; I reviewed and tested the changes.