fix: improve diagnostics when env-based token fails auth

What does this MR do and why?

When glab auth status hits a 401 and the token source is an environment variable, it's very hard to debug — especially when a wrapper like 1Password's op plugin run -- glab is silently injecting a different or expired token via GITLAB_TOKEN.

This MR makes two improvements to glab auth status:

1. Specific env var name in the footer warning — instead of listing all three possible env var names, show the one that's actually set:

   Before: ! One of GITLAB_TOKEN, GITLAB_ACCESS_TOKEN, OAUTH_TOKEN environment variables is set. It will be used for all authentication.
   After:  ! Token is from environment variable GITLAB_TOKEN. This takes precedence over tokens stored in config or keyring.
           If a wrapper (e.g., 'op plugin run -- glab') is setting this, run type glab in your shell to check.

2. Actionable hint on 401 failures — when auth fails and the token came from an env var, surface three extra lines pointing at wrapper injection as a likely cause:

   x gitlab.com: API call failed: GET .../user: 401 {error: invalid_token}
     ! Token is from environment variable GITLAB_TOKEN. A wrapper may be injecting a different or expired token.
     ! To investigate, run in your shell: type glab
     ! To see the token value in use, run: env | grep -E 'GITLAB_TOKEN|GITLAB_ACCESS_TOKEN|OAUTH_TOKEN'

type glab is suggested rather than which glab because type is a shell built-in that shows alias definitions (e.g. glab: aliased to op plugin run -- glab), whereas which only resolves binary paths and won't surface shell aliases in a subprocess.

Related issues

Closes #8238 (closed)

MR acceptance checklist

• Appropriate tests are included