GitLab issues not loading: glab fails on repos without matching GitLab remote

[dhilgaertner]

Summary

GitLab tickets are not appearing in the ticket list. IssueTracker.fetchGitLabIssues fails whenever glab issue list runs against a repository whose configured remotes don't match GITLAB_HOST, so the entire GitLab fetch aborts and no GitLab issues are returned.

Error from logs

[IssueTracker] fetchGitLabIssues(host: repo1.dso.mil) failed: Error Domain=IssueTracker Code=1
"`glab issue list -a @me --output-format json` exited 1: ERROR

  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 repo1.dso.mil Configured
  remotes: github.com."

Immediately followed by:

[IssueTracker] refresh: 3 gh calls in 4.25s, GraphQL 4667/5000 remaining, resets in 28m

— so GitHub issues come back fine, but GitLab returns nothing.

Root cause

glab issue list resolves the host from the current working directory's git remotes. If GITLAB_HOST is set to a host that none of the remotes match (e.g. CWD is a GitHub-only repo, or a repo with only github.com remotes), glab refuses to run rather than falling back to the env-var host.

Suggested fix

A few options — pick whichever fits IssueTracker's design:

1. Run glab issue list outside of a git-tracked CWD (e.g. a neutral temp dir or $HOME) when querying a specific host via GITLAB_HOST, so glab doesn't try to reconcile against the current repo's remotes.
2. Pass the host explicitly via --repo / glab's host flags instead of relying on the CWD + GITLAB_HOST combination.
3. Detect this specific error and treat it as "no matching remote, skip gracefully" rather than bubbling up a fatal error that kills the whole GitLab fetch.

Expected behavior

fetchGitLabIssues(host:) should return the user's assigned issues from that host regardless of which repo Claude Code / Crow happens to be running from.