fix: report actual error when auth status token check fails for non-401 - #14054

Summary

gh auth status currently renders "The token in <source> is invalid." for any token-verification failure: 401, 403 rate limit, 5xx, and network/DNS errors all produce the same misleading message plus a "To re-authenticate, run: gh auth refresh" hint that only makes sense for genuinely invalid or revoked tokens. Refreshing while rate limited does not help, and the message actively misleads users (and agents reading the output) into thinking their token is dead.

This PR records the HTTP status code of the verification request and only reports the token as invalid for 401 Unauthorized. For every other failure it surfaces the actual error instead, and the re-auth/logout hints are only shown for genuine auth failures.

This follows existing precedent in the codebase rather than introducing a new mechanism:

• internal/ghcmd/cmd.go already special-cases errors.As(err, &api.HTTPError) && httpErr.StatusCode == 401 for the "Try authenticating with" hint (Print gh auth refresh for 401 returns #13068).
• Timeouts were misreported the same way and received a dedicated state (Connection timeout is incorrectly reported as invalid token #8293); this addresses the remaining error cases.

Real-world trigger: an agent daemon sharing the same token exhausted the account's API quota, and gh auth status kept reporting the token as invalid with a useless refresh hint - the token itself was fine and worked again after the rate limit reset. The same misleading output appears for sandboxed/network-restricted environments (DNS failures, blocked connections), as documented in #12891.

Changes

• pkg/cmd/auth/status/status.go
  • authEntry gains a StatusCode field (exposed in --json output as statusCode, omitted when unset).
  • buildEntry records the status code from api.HTTPError when the scopes request fails.
  • String() now renders:
    • 401 - unchanged: "The token in <source> is invalid." plus re-auth/logout hints.
    • anything else - "Could not verify token in <source>: <actual error>" with no re-auth hint.
• pkg/cmd/auth/status/status_test.go
  • "bad token" cases now stub 401 (the real status for bad credentials) instead of 400.
  • New "rate limited" case stubs a 403 rate-limit response and asserts the new message and the absence of the re-auth hint.
  • JSON case asserts the new statusCode field.

Known limitations (deliberately out of scope)

• Env-token path: tokens from GH_TOKEN/GH_ENTERPRISE_TOKEN are validated via a GraphQL call (CurrentLoginName) whose errors do not carry an HTTP status code, so the statusCode-based discrimination does not apply there; a genuinely invalid env token reports "Could not verify token" with the underlying error rather than "invalid". Fixing this requires touching the GraphQL client's error surface.
• SSO-enforced 403s (403 + X-GitHub-SSO header) keep their existing handling; that flow is managed separately in internal/ghcmd via the SSO URL mechanism.

Test plan

• go test ./pkg/cmd/auth/status/... - all pass.
• go build ./... - clean.

Related

• Fixes gh auth status should distinguish transport failures from invalid credentials #12891 (gh auth status should distinguish transport failures from invalid credentials)
• Also addresses gh auth status reports rate limit / network failures as "token is invalid" with misleading re-auth advice #14053 (reported rate-limit misreporting; triaged as a duplicate of gh auth status should distinguish transport failures from invalid credentials #12891)