Refreshable tokens (5/7): gh auth status short-lived token details - #14454

Part of #14449. Based on #14453 (auth token).

Description

Teaches gh auth status to show short-lived token details and to refresh the token as part of reporting status, so what it displays reflects a currently valid credential rather than a stale or expired one.

How did you test this change?

This feature is verified end to end as a whole rather than per PR. End-to-end tests should pass.

Key points

• Status now surfaces the expiry information that a short-lived token carries and a non-expiring token does not. This makes the difference between a permanent and a refreshable credential visible to the user at a glance.
• Reporting status resolves the active token, so it goes through the same refresh path as the other consumers (HTTP transport, gh auth token, the git credential helper). That means a short-lived token whose access token has expired is refreshed and reported as valid, rather than being surfaced as broken. Status reflects the credential gh would actually use, not a stale snapshot.
• Because the refresh goes through the shared serialized path from PR 2, running gh auth status concurrently with another gh process cannot double-spend the refresh token.

Notes for reviewers

Focus on the status output formatting for the refreshable case and the point where resolving status triggers a refresh. Confirm the non-refreshable path is unchanged.

Commit:

• fix(auth status): show and refresh short-lived token details

Authorship and follow-up

Who wrote this:

• A human wrote it.
• An agent wrote it under close human direction.
• An agent wrote it independently, and no human has guided the implementation beyond the initial prompt.

Who answers review comments:

• @babakks will read and reply directly.
• An agent will draft replies and @username will read them before they are posted.
• Nobody has explicitly committed to replying.