Qodana Cloud CI tokens: long-lived project token vs scheduled rotation for upload credentials

We run Qodana linters in CI and upload results to Qodana Cloud using the QODANA_TOKEN environment variable, one project token per pipeline. The token is stored as a CI secret, and I want to settle on a credential policy before rolling this out to more repositories.

The trade-off I cannot resolve from the documentation alone: a long-lived project token is operationally simple and already scoped to a single project, but if a CI secret leaks, it stays valid until someone revokes it manually. Scheduled rotation limits that exposure window, yet Qodana does not appear to prescribe or automate rotation, so every rotation is a manual secret update across pipelines, and a missed rotation means uploads start failing.

A related concern is failure visibility. My understanding is that an expired or revoked token does not stop the local analysis or the quality gate, which are evaluated by the linter itself — only the cloud upload fails, so dashboards silently go stale unless someone watches pipeline logs.

Specific questions:

1. For teams running Qodana at scale, is a long-lived per-project token an acceptable least-privilege posture, or is rotation expected practice?
2. When a token is expired or revoked, does the upload step fail the CI job loudly, or only warn — and does this differ between the GitHub Action and the Docker-based integration?
3. Is there any supported way to detect stale uploads (e.g., alerting on missing reports) rather than relying on log inspection?