Invalidate active remote sessions after organization access downgrade or revocation

[maxvint]

Problem

An already-issued remote session keeps its signed editor capability after the underlying Organization access is downgraded or revoked.

This was reproduced end to end on staging with the same Organization member signed into two hostnames for one Instance:

• Instance: inst_R8Y2tmapzrAjuFFH
• Organization: org_GFE5xcw8E0pGtV-X
• max-app.avibe.tech received an editor session through the Research group.
• Research was then changed back to viewer.
• After reloading, the existing session still rendered New session in this project, the chat textbox, and the Send control.
• The member was subsequently removed from the Organization, but no mechanism invalidated the already-issued local session.

This is not only a stale UI projection. The local runtime continues trusting the old signed claims until session expiration or explicit reauthorization.

Required behavior

Downgrading or revoking access must invalidate active authorization promptly across every hostname for the Instance. This includes:

• member removal from the Organization
• removal from an authorized group
• group archival
• Instance role downgrade, for example editor -> viewer
• removal of the Instance access binding

HTTP mutations, SSE, WebSocket connections, resumed streams, and newly opened pages must all converge on the current authorization decision. Shortening the cookie lifetime alone is not sufficient.

Use a versioned revocation design such as membership/access revisions, a device-synchronized revocation watermark, or a narrowly scoped online introspection mechanism. The runtime must fail closed when a previously signed authorization version is stale.

Acceptance criteria

• An active editor session loses chat/session-creation capability after an Instance role downgrade without waiting for natural cookie expiry.
• Removing a member or removing the granting group membership invalidates all of that member's active sessions for the Instance.
• Default and custom hostnames cannot retain divergent authorization indefinitely.
• Existing HTTP, SSE, and WebSocket paths re-check the same revocation state.
• Trusted local access remains owner-equivalent and is not coupled to hosted membership checks.
• Tests cover downgrade, group removal, member removal, stale revision, reconnect, and multi-host sessions.
• Staging E2E proves an old editor session becomes viewer or is forced through reauthorization.

Implementation context

The original signed-role implementation is useful context but does not cover the staging revocation failure:

• Consume signed instance roles and enforce viewer/editor runtime capabilities #981
• avibe-bot/avibe-backend#70
• avibe-bot/avibe-backend#73