gh auth status reports rate limit / network failures as "token is invalid" with misleading re-auth advice #14053

Describe the bug

gh auth status reports "The token in <source> is invalid." for any token-validation failure, not just 401 Unauthorized. A 403 rate-limit response, a 5xx, or a TLS/DNS failure all produce the same misleading message plus a "To re-authenticate, run: gh auth refresh" hint that is useless (or actively harmful) for non-auth failures.

In pkg/cmd/auth/status/status.go, buildEntry only special-cases network timeouts; every other error collapses into authEntryStateError, and authEntry.String unconditionally renders "The token in %s is invalid." for that state — the actual error is only visible via --json hosts (entry.error).

Steps to reproduce the behavior

1. Exhaust the account's API rate limit (e.g. an agent/CI loop hitting the API, or a shared token used by another process).
2. Run gh auth status.

Actual output:

github.com
  X Failed to log in to github.com account <user> (keyring)
  - Active account: true
  - The token in keyring is invalid.
  - To re-authenticate, run: gh auth refresh -h github.com
  - To forget about this account, run: gh auth logout -h github.com -u <user>

3. The token is actually fine: curl -H "Authorization: Bearer <token>" https://api.github.com/user returns 403 with API rate limit exceeded for user ID ..., and succeeds again once the limit resets — no re-authentication involved.

Expected vs actual behavior

Expected: distinguish 401 (genuinely invalid/revoked token → "invalid" + re-auth hint) from other failures (rate limit, server error, network), and surface the real error — e.g. "Could not verify token: API rate limit exceeded for user ID ...".

Actual: every failure is reported as an invalid token, and the suggested fix (gh auth refresh) does nothing for rate limits — refreshing while rate limited makes the validation request fail again, so the situation appears worse.

Additional context

• gh version 2.96.0; same code on trunk.
• Related: Connection timeout is incorrectly reported as invalid token #8293 — timeouts used to be misreported the same way and received a dedicated timeout state; this issue is the same class of problem for every other error type.
• The detail is already collected (entry.Error) but only exposed through --json hosts; a status-code-aware message in the human-readable output would resolve this.