Show real token expiry by parsing the JWT `exp` claim instead of the requested value

[saadqbal]

Problem

`tracebloc cluster info` prints:

```
expires in: ~10m0s (server may cap shorter)
```

That's the *requested* expiration. The kube-apiserver may cap shorter via `--service-account-max-token-expiration` (often set to 1h or shorter on hardened clusters). Customers reading the displayed value and pasting it into a script expecting that exact validity window get confusing 401s when the token actually expires earlier.

Fix

After `MintIngestorToken` succeeds, parse the JWT's `exp` claim and show the actual expiration window:

```go
import "github.com/golang-jwt/jwt/v5" // or hand-roll: the JWT payload is base64-decoded JSON

claims := jwt.MapClaims{}
// JWT format: header.payload.signature; we only need the payload
parts := strings.Split(tok.Token, ".")
if len(parts) == 3 {
payload, _ := base64.RawURLEncoding.DecodeString(parts[1])
_ = json.Unmarshal(payload, &claims)
if exp, ok := claims["exp"].(float64); ok {
actualExp := time.Until(time.Unix(int64(exp), 0))
printf "expires in: %s (server-decided)", actualExp
}
}
```

Hand-rolling avoids the jwt dep + signature-validation complexity — we don't need to verify the token, we just want to read its expiry.

Static-secret tokens are unbounded; existing "never (static-secret fallback)" message stays accurate.

Acceptance criteria

• A TokenRequest-minted token with a server-capped expiration displays the capped value, not the requested one
• The displayed window decrements correctly across multiple invocations of the same minted token (verify by storing + re-displaying)
• Static-secret path unchanged
• Malformed JWT (truncated, wrong format) falls back gracefully to the requested-value display rather than crashing

Found by

Self-review of PR #2. Filed as v0.2 hardening; the existing display is accurate-enough for the MVP and the misleading-window concern doesn't actually break any v0.1 flow (the token is short-lived enough that customers don't keep it around).

[github-actions]

👋 This issue has had no activity for 6 weeks.

If it's still relevant, please leave a comment with current context (or assign someone). Otherwise it will auto-close in 2 weeks.

To exempt permanently, add the keep-open label.

[LukasWodka]

🔎 Refinement deep-dive — verified on develop a2c5816

Still valid: confirmed reproduces. cluster.go:211 prints the requested value: p.Field("expires in", "~%s (server may cap shorter)", exp) from tok.ExpirationSeconds. Root cause is upstream: MintIngestorToken (token.go:19-21) builds IngestorToken{Token: tr.Status.Token, ExpirationSeconds: expirationSeconds, …} — it uses the requested seconds and discards tr.Status.ExpirationTimestamp, the server's authoritative, capped grant from the TokenRequest response. No JWT parsing exists. cluster info survives the Rev-9 surface trim.

⚠️ Recommend a better fix than this issue's title. Don't parse the JWT exp claim — the TokenRequest response already tells us the real expiry (Status.ExpirationTimestamp, capped by --service-account-max-token-expiration). Surfacing that is exact, needs no new dependency, and no base64url/JSON/clock-skew decoding. JWT-parsing would only re-derive what the server already stated, and the static-secret fallback path has no meaningful exp anyway.

Fix (size XS–S, independently shippable):

• token.go — add ExpiresAt time.Time to IngestorToken; in the TokenRequest branch set ExpiresAt: tr.Status.ExpirationTimestamp.Time. Static-secret branch leaves it zero.
• cluster.go — if !tok.ExpiresAt.IsZero() → "expires in ~%s" from time.Until(tok.ExpiresAt).Round(time.Second) (the real grant); else if ExpirationSeconds > 0 → keep today's requested-value line as fallback; else "never (static-secret fallback)".

Tests: token_test.go — fake CreateToken reactor returns a TokenRequest with Status.ExpirationTimestamp set; assert MintIngestorToken populates ExpiresAt (fails today — field doesn't exist). A cluster info render assertion that the "expires in" line reflects the server timestamp when present.

Edge/risk: client/server clock skew — time.Until uses the local clock; the "~" hedge already covers it (note in code). Zero timestamp → requested-value fallback. Static-secret → "never". The whole point: when the server caps below --token-expiry, we now show the capped value. Shares cluster/token files with #7 (different regions).

Priority: LOW — the issue itself notes it breaks no v0.1 flow (tokens are short-lived, so the misleading window is small). Genuinely valid, not obsolete — the stale label was misleading.

Ready for refinement (low priority).

[saadqbal]

ExpiresAt now parsed from TokenRequest.ExpirationTimestamp (token.go:117); merged to main+develop (PR #176/#177).