feat(auth): warn when env token overrides stored credentials

What does this MR do and why?

glab auth status already nudges users toward the keyring and reports when a token comes from an environment variable:

! Token is from environment variable GITLAB_TOKEN. This takes precedence over tokens stored in config or keyring.

But glab auth login gave no such guidance. A common failure mode: a user runs glab auth login to move credentials into the keyring, but a GITLAB_TOKEN exported from a shell dotfile keeps overriding it, so nothing actually changes for them.

This MR adds a post-login warning and makes the env-token guidance actionable and consistent across both commands.

Changes

• Warn after glab auth login. When a token is set through an environment variable, the --token and interactive/web/device flows now warn that it takes precedence over the credentials just stored. Job token logins are intentionally excluded: those tokens are environment-supplied and only valid while the job runs, so the nudge to remove the variable does not apply.
• Diagnose the source instead of assuming it. The warning leads with type glab and spells out both outcomes:
  • An alias such as op plugin run -- glab (for example, a 1Password shell plugin) means a wrapper is injecting the token, which is expected and needs no action.
  • A plain path means the token is set in the shell environment (for example, a dotfile like ~/.bashrc or ~/.zshrc) and should be removed there so glab uses the stored credentials.
• Consistent glab auth status guidance. The same actionable "remove it from your environment" line and type glab explanation are added to the status env-token warning, so a plain-path result is no longer mystifying.

The 401 diagnostic in glab auth status is deliberately left as is: there, a wrapper injecting a different or expired token is the problem to investigate, not an expected no-op.

Example output (glab auth login)

✓ Stored your credentials in the operating system keyring.

! The environment variable GITLAB_TOKEN is set and takes precedence over the credentials just stored.
  Run type glab to find the source: an alias such as 'op plugin run -- glab' means a wrapper (for example, a 1Password shell plugin) is injecting it, which is expected and needs no action.
  A plain path means it is set in your shell environment (for example, a dotfile like ~/.bashrc or ~/.zshrc); remove it there so glab uses the stored credentials.

How to test

1. export GITLAB_TOKEN=glpat-...
2. glab auth login --hostname gitlab.com --token glpat-...
3. Observe the new warning after the "Stored your credentials..." line.
4. Run glab auth status and confirm the env-token warning shows the same guidance.
5. unset GITLAB_TOKEN and repeat login; the warning should not appear.

MR acceptance checklist

• Tests added/updated (login and status packages).
• go build, go vet, gofmt, and the internal/commands/auth/{login,status} test suites pass.