Improve auth status command to detect invalidated refresh tokens

[gentamura]

Summary

The listee auth status subcommand currently reports accounts based solely on refresh tokens stored in the keychain. When a user is removed from Supabase Auth, their refresh token becomes invalid, yet the CLI still shows them as “Logged-in accounts,” which can mislead operators into believing the session is usable.

Current Behavior

Running listee auth status lists every account found in the keychain, even if Supabase has revoked or deleted the corresponding user.

Problem

This mismatch between the CLI status and the actual Supabase authentication state causes confusion. Operators must run listee auth logout manually or attempt another action to discover that the stored session is no longer valid.

Proposal

When auth status executes:

1. Attempt to refresh each stored session by calling auth/v1/token?grant_type=refresh_token with the saved refresh token.
2. If the refresh succeeds, keep the account in the “Logged-in accounts” list.
3. If the refresh fails (e.g., 400/401 or a token-format error), mark that account as requiring re-authentication and show a message such as “Token invalid — please run listee auth login.”
4. Handle offline scenarios gracefully (skip validation when Supabase isn’t reachable and warn the user).

Alternatives

Leave the command as-is and rely on manual auth logout, though this keeps the confusing status output.

Open Questions

• Should we cache negative results to avoid hitting Supabase on every run?
• Do we need a flag to disable verification for environments without network access?