fix(cli): show the real (server-capped) ingestor token expiry (#4)

[LukasWodka]

Closes#4.

Problem

tracebloc cluster info printed the requested token lifetime — expires in ~10m0s (server may cap shorter) from ExpirationSeconds — even when kube-apiserver's --service-account-max-token-expiration capped the grant shorter. The customer saw a lifetime the token doesn't have.

Fix (not the issue's JWT approach — better)

The TokenRequest response already carries the authoritative expiry (TokenRequestStatus.ExpirationTimestamp, capped by policy). No JWT parsing, no new dependency. Capture it as IngestorToken.ExpiresAt:

• ExpiresAt set → cluster info shows ~<time.Until(ExpiresAt)> (the real remaining lifetime; ~ hedges client/server clock skew);
• not set → fall back to the requested value (~10m0s (requested; server may cap shorter));
• static-secret fallback → ExpiresAt stays zero → still reads never.

Tests (internal/cluster/token_test.go)

• CapturesServerExpiry — reactor caps 3600→300s; asserts ExpiresAt reflects the cap (the exact Show real token expiry by parsing the JWT exp claim instead of the requested value #4 scenario).
• StaticSecretHasNoExpiresAt — fallback path → zero ExpiresAt → never.

Full internal/... suite + go vet + gofmt green.

Low priority per the issue (short-lived tokens = small misleading window), but a cheap correctness win. Touches token.go + the cluster info display; only textual overlap with #7 (also in cluster/token files, different regions).

🤖 Generated with Claude Code

[saadqbal]

Clean fix 👍 — reading ExpirationTimestamp off the TokenRequest response instead of parsing the JWT is the right call. Verified the static-secret path still falls through to "never" (ExpirationSeconds 0 + zero ExpiresAt), and the ~ hedge on time.Until covers clock skew. Built + tested locally, green. LGTM.

[saadqbal]

/fr-pass