THREE distinct causes answer this status:

• a role that is not admissible in this tenant type, or a crypto role on a HUMAN
  user;
• a role the catalogue marks service-to-service only;
• a granular SCOPE-CATALOGUE entry submitted as an assignable role. The roles
  table carries one row per scope literal beside the composite roles; such a row
  carries no scope set and expands to no authority, so assigning it would persist
  a grant that confers nothing. detail names the offending role.

All three are all-or-nothing: if ANY submitted role is rejected, the whole
request is, and no assignment is written.

THREE distinct causes answer this status, and a consumer should branch on type:

• .../errors/forbidden — access denied to the tenant, or an insufficient scope.
• .../errors/scope-subset-violation — the assignment would confer on the target
  an authority the CALLER does not itself hold (the subset rule; PRD §232
  FR-232.13). extensions.missingScopes carries exactly those requested scopes
  the caller lacks, and extensions.rule names the rule. A delegate never
  exceeds its delegator, so the repair is to widen the CALLER's own roles or to
  assign a narrower role — not to retry.
• .../errors/impersonation-operation-forbidden — the caller is acting under a
  support-access impersonation session. The operator holds
  admin.tenant.user.roles.update and is inside the tenant boundary; the refusal
  is not an authorization failure. A role grant PERSISTS after the consent
  window, so it widens what an identity may do at every future login rather than
  only during the support session. The refusal binds on SaaS deployments only
  (PRD §148): SaaS is the only place ANKATech operates a tenant belonging to
  somebody else.

User or tenant not found