k6 Cloud upload: generic auth errors persist despite K6_CLOUD_TOKEN to K6_TOKEN rename

k6 Cloud result uploads rely on an API token passed via environment variable — historically K6_CLOUD_TOKEN, now aligned with K6_TOKEN — but the runtime does not validate token lifetime locally, nor does it refresh tokens automatically. When a token expires or is revoked, the upload fails with a generic cloud error that does not distinguish authentication expiry from network issues, service downtime, or quota limits. This forces test authors to infer the root cause from context rather than from a structured error signal.

The transition between environment variable names across versions adds a compatibility boundary: scripts using the legacy name may silently fail to authenticate if the new name is required, yet the error surface remains the same. Meanwhile, HTTP request authentication in k6 is static per virtual user; there is no built-in credential rotation, automatic re-authentication on 401/403, or least-privilege scope enforcement. The browser module can automate login flows, but session expiry and token refresh must be implemented in script code.

Given the unresolved decision on whether k6 will surface token expiry as a distinct error class and whether future versions will support short-lived tokens with refresh helpers, the following questions remain:

1. Will k6 introduce a dedicated error code or message category for expired or revoked cloud tokens, separate from generic upload failures?
2. Is a token-refresh helper or short-lived token pattern planned for long-running cloud test executions?
3. What is the recommended strategy for scripts to reliably detect token expiry today without parsing error strings?