Gatsby source plugin token expiration handling configuration

When a Gatsby source plugin reads an authentication token from an environment variable at build time, the plugin passes the token to the remote API without checking whether the token has expired. If the token is stale, the API returns 401/403 and the build fails with a generic “Unauthorized” or “Failed to fetch” message that does not indicate token expiration as the root cause. This forces developers to inspect logs or manually verify token validity to diagnose the failure, which can delay detection of credential issues and violate least‑privilege expectations that credentials should be validated before use.

The current behavior leaves the responsibility for token rotation entirely to the deployment pipeline or the developer, with no built‑in mechanism to warn about stale credentials before the build starts. Considering the need for early detection, what approach should be taken to add expiration awareness to source plugins? Should plugins expose an optional flag that triggers a pre‑flight token validation step, or should Gatsby core provide a middleware that checks token validity and emits a warning? How can such a check be implemented without exposing the token value in logs or breaking existing workflows?