Role updated. A scope SHRINK immediately invalidates every live token of every holder of this role. Because the verb REPLACES the scope set, saving a set that does not contain the previous one is a withdrawal of permission, and a permission already minted into a token would otherwise keep working until that token expired. The platform therefore advances the revocation epoch of each holder, so their next request against any resource server is rejected and they must obtain a fresh token. The holders of a tenant custom role are human users, via user_roles; a Cryptographic Actor cannot hold one, because actor_roles admits only the global, non-system catalog roles. Widening a scope set, or replacing it with an equal or larger one, revokes nothing.

Subset-rule violation, a system-role attempt, or the caller is acting under a support-access impersonation session (impersonation-operation-forbidden). The last is a DISTINCT cause and not an authorization failure — the operator holds admin.tenant.role.update and is inside the tenant boundary. This verb REPLACES a role's scope set, so widening a role the tenant already assigns escalates every holder of it, permanently, without touching any identity — which is why it is denied even though it mints nothing. It binds on SaaS deployments only (PRD §148): SaaS is the only place ANKATech operates a tenant belonging to somebody else. Branch on type, not on the status.

Optimistic-lock conflict OR concurrent modification