Thanks for the detailed timeline. It matches how API Server 2.0.2608.10 works by design. This behavior originally came from security requirements in Laserfiche Cloud. We will revisit making it configurable for self-hosted, but there is no ETA.

1. Should refresh-token rotation extend the expiration? Refreshing does extend the expiration of the new access token. Every refresh returns a new access token that's valid for the full AccessTokenExpirationLimit from the time of the refresh. BUT, the refresh token's expiration can't be extended. It's set once, when the authorization code is exchanged for tokens, to that time + AccessTokenExpirationLimit + SessionIdleTimeout, and every rotated refresh token keeps that same deadline. With your settings (00:15 / 00:15) that's 30 minutes, which is why it stayed at 8:38:17 PM. After that, refreshing fails with HTTP 400 and the user has to sign in again through the authorization-code flow. The last access token you received is still valid until its own expiration, which is why your requests kept working until 8:49:12 PM.
2. Could refreshing early cause this? No. Every new refresh token gets the same expiration no matter when you refresh, so refreshing early doesn't shorten or extend anything. The server-side session isn't the cause either. It times out only after SessionIdleTimeout with no requests, and every request resets that timer, so your 60-second polling keeps it alive. The later you refresh and get your last access token inside the refresh window, the later your final access token will last.
3. Is there a supported way to keep an active session alive without user interaction? The easiest way to extend the session with no user interaction is to increase AccessTokenExpirationLimit  and SessionIdleTimeout. An access token is considered valid for AccessTokenExpirationLimit after it was issued as long as the session hasn't been idle longer than SessionIdleTimeout. Refreshing can give you a new access token which has a new expiration of AccessTokenExpirationLimit from the time of refresh. BUT the refresh must occur before that original refresh expiration (making one refresh right after access token expiration the most intended use case). After that, the user has to sign in again. There is no setting in this version that lets a refresh extend the refresh token.
4. SessionIdleTimeout or IdleSessionTimeout? SessionIdleTimeout is the setting this version reads. IdleSessionTimeout was an older name from version 1. The Session Management section of the authentication page is out of date