Auth token expiration blocks all commands — no auto-reauth flow

[vsilent]

Description

When the Stacker auth token expires, all commands fail with:

Error: Authentication token expired. Run: stacker login

There's no auto-reauth flow or token refresh mechanism.

Affected Projects

activepieces, all cloud/server deploys after token expiry

Steps to Reproduce

1. Login: stacker login
2. Wait for token to expire (or use an old token)
3. Run any command: stacker status, stacker deploy, etc.
4. Command fails with auth error

Expected Behavior

• Auto-refresh token if possible
• Or prompt for re-login interactively
• Or provide a stacker login --refresh command

Current Workaround

Manual stacker login before each session.

Environment

• Stacker CLI version: latest

[vsilent]

Correction: the "not actually expired" claim below was based on a flawed timeline — I read credentials.json's expires_at after re-logging in in response to the failure, so it reflected the fresh token's expiry, not the one that actually failed. That's not valid evidence the original token was still good. Retracting that specific claim; apologies for the noise.

What still stands from this session: three separate "Authentication token expired" failures required manual stacker login each time, well within a single working session — so the core ask here (auto-refresh using the refresh_token that's already being persisted in credentials.json) is still clearly worth doing, I just can't back up "the error is sometimes wrong about actual expiry" with real evidence anymore.

---

Original (partially retracted) comment:

Additional evidence that sharpens this: in my case, the "Authentication token expired" error fired even though the token was not actually expired.

~/.config/stacker/credentials.json recorded:
```json
"expires_at": "2026-08-22T21:47:51.560373Z"
```
at a point where the current time was `2026-08-22T13:48:25Z` — i.e. ~8 hours of validity still remaining. Yet `stacker deploy --target cloud ...` failed with:
```
Error: Authentication token expired. Run: stacker login
```
No re-login was performed. (Correction: a re-login was performed in between by the human operator, which I wasn't tracking — see correction above.) Running the exact same command again a few minutes later succeeded.

Also worth noting: `credentials.json` stores a `refresh_token` alongside `access_token`, but nothing in the CLI appears to use it — supports the "auto-refresh token if possible" ask in the issue description, since the raw material for that is already being persisted.

[vsilent]

Implemented auto-refresh. CredentialsManager::require_valid_token (src/cli/credentials.rs) now transparently exchanges the stored refresh_token for a new access token via the standard OAuth2 grant_type=refresh_token grant (RFC 6749 §6), posted to the same token endpoint used for login, before falling back to TokenExpired. On success the new credentials are persisted, so the next command doesn't hit the same wall.

Since refresh_token was already being captured and persisted (per your comment) but never used, this is additive — the 20 existing require_valid_token() call sites across the CLI are unchanged (same signature, same sync/no-runtime-required behavior); the refresh attempt is entirely internal.

Fails closed everywhere it should: no refresh_token on file, no resolvable auth URL, a legacy direct-login endpoint with no OAuth refresh concept, or the refresh call itself failing (expired/revoked refresh token, network error) — all of these fall straight through to the existing TokenExpired error and stacker login prompt, never a new/different failure mode.

Caveat I want to be upfront about: I implemented this against the standard OAuth2 refresh grant shape, matching the same conventions the existing password and device_code grants in this file already use against the same endpoint — but I don't have a live auth backend to verify the exact response contract against. If the User Service's token endpoint doesn't actually implement grant_type=refresh_token, this degrades safely to today's behavior (refresh attempt fails silently, same TokenExpired error as before) rather than breaking anything — but it also won't actually fix the problem until confirmed against the real endpoint. Would appreciate someone with backend access confirming/adjusting the grant shape if it differs.

7 new tests (refresh success incl. identity-field carryover and refresh_token-not-rotated handling, fallback on failure, skip-when-no-refresh-token, and full manager-level wiring). Full suite: 1821 passed, 0 failed, run 3x to rule out flakiness from the one test that touches STACKER_AUTH_URL (properly scoped/locked/cleaned up).

Not committed — same pattern as this session's other fixes.