Slack token rotation limits: user token expiry behavior without bot token rotation

When a granular-permission Slack app opts into token rotation, the documented behavior introduces short-lived user access tokens paired with refresh tokens, while bot tokens reportedly remain non-expiring until uninstall or workspace reset. This asymmetry creates an unresolved design boundary: an app may need to bound user-token lifetime for least-privilege hygiene, yet still manage long-lived bot credentials under a different expiry model.

The exact access-token lifetime, refresh-token reuse rules, and whether classic or Enterprise Grid configurations follow the same pattern are version-sensitive and not fixed across all Slack app types. Because auth.test returns token metadata and scopes but does not confirm whether a rotated token is still within its active window, client-side expiry tracking is required regardless.

Is the non-expiring bot-token behavior guaranteed for all granular-permission apps when rotation is enabled, or does it vary by workspace plan or app configuration? What is the current documented lifetime for a rotated user access token, and are refresh tokens single-use with mandatory rotation on every exchange? Should least-privilege implementations assume bot tokens never expire, or must they handle eventual bot-token invalidation separately from user-token refresh logic?