feat: fire user.Deactivating from the admin deactivate action

- DeactivatingEvent and DeactivatingEventName in classes
- FireDeactivatingEvent modelled on FireDeletingEvent
- the deactivate bulk action runs DeactivateUsers unchanged, then fires
  the event per newly deactivated user in the action's transaction

classes/events.go

@@ -11,6 +11,9 @@ const CreatedEventName = "user.Created"
 // DeletingEventName is the festival name of DeletingEvent (D-13 / RESEARCH A6).
 const DeletingEventName = "user.Deleting"
 
+// DeactivatingEventName is the festival name of DeactivatingEvent.
+const DeactivatingEventName = "user.Deactivating"
+
 // GetApiArrayEvent is the fire-and-collect payload other plugins extend.
 type GetApiArrayEvent struct {
 	User *models.User
@@ -52,3 +55,13 @@ type DeletingEvent struct {
 	User *models.User
 	Tx   *gorm.DB
 }
+
+// DeactivatingEvent fires after a user is soft-deleted (deactivated, the
+// PHP $user->delete()) by the admin deactivate action, inside the same
+// transaction, so listeners can revoke what a deactivated account must not
+// keep (OAuth grants, for example) while leaving what a restore needs. A
+// listener error rolls the deactivation back.
+type DeactivatingEvent struct {
+	User *models.User
+	Tx   *gorm.DB
+}