Transitions the aggregate SUSPENDED → ACTIVE and cascades to the owned Cryptographic Actor, which returns to ACTIVE and has its signed effective-status envelope republished, so crypto operations and new token requests both succeed again.

Because suspend revoked nothing, resume recreates nothing: the same Capability Grants, the same never-rotated Actor Credential and the same constraint counters are still in place.

Resume restores the actor unconditionally. An actor suspended directly on the actor plane — an incident response, say — is cleared by this call too; the platform stores no reason or owner that would distinguish the two suspensions. The actor's pre-transition status is recorded in the audit trail under this request's correlation id.

The cascade runs inside this request's transaction: an actor already ACTIVE is a satisfied step (200, no second write); an actor DISABLED is refused 422 under its OWN problem type, .../terminal-actor-state, so a client can tell “retrying is pointless, revoke instead” from “you sent the wrong verb” without string-matching the detail. Idempotent on an already-ACTIVE aggregate → 422, and a concurrent transition → 422 as well, never 409 — the row is held under PESSIMISTIC_WRITE, so the loser reads COMMITTED state rather than failing an optimistic-lock check. Scope: admin.tenant.internal-use-case.resume