Gitter OAuth sessions: revoke at the provider or force re-authentication in Gitter

Context

Gitter delegates primary authentication to external OAuth2 providers such as GitHub and GitLab, then maintains its own session via internal cookies. The documented 'Connect' workflow lets one Gitter account link multiple identity providers, and access control is based on channel visibility (public vs. private) rather than granular per-message roles.

The constraint

For a team running private Gitter rooms, I need a least-privilege posture: when a member leaves or a token is compromised, access should end promptly. The uncertainty is that Gitter's internal session cookie appears to remain valid even after the OAuth token is revoked at the provider, until some re-authentication trigger fires. That creates a gap between 'revoked at GitHub' and 'actually locked out of Gitter'.

The trade-off

Option A: rely on provider-side revocation (removing Gitter from GitHub's Authorized OAuth Apps) and accept whatever session persistence Gitter applies. Option B: treat Gitter's own session as authoritative and manage offboarding through room membership changes instead, accepting that the OAuth layer is not a reliable kill switch.

Questions

1. Which documented mechanism actually terminates an active Gitter session fastest: provider token revocation or removing the user from private rooms?
2. What event forces Gitter to re-check the external provider token, and is that interval configurable or documented?
3. Does the multi-provider Connect workflow change revocation behavior if only one linked identity is revoked?