Define tenant lifecycle event contract

docs/TENANCY_MODULE_BOUNDARY.md

@@ -27,3 +27,29 @@ their owning modules before physical deletion.
 Tenant lifecycle planning uses registered tenant summary providers and delete
 veto providers. Modules that own tenant-scoped data must contribute summaries
 so destructive deletion cannot silently miss their rows.
+
+## Lifecycle Events
+
+`govoplan-tenancy.backend.lifecycle` is the module-local contract for tenant
+lifecycle event names and payload shape. Modules that need to react to tenant
+lifecycle changes should depend on the event type strings or the emitted audit
+events, not on tenancy API route internals.
+
+The stable lifecycle event names are:
+
+- `tenant.created`: tenant registry entry was created and owner membership
+  provisioning was requested.
+- `tenant.suspended`: tenant was marked inactive through the admin lifecycle
+  route.
+- `tenant.resumed`: tenant was reactivated through the admin lifecycle route.
+- `tenant.deletion_requested`: retirement or destructive erasure was requested
+  after lifecycle planning passed.
+- `tenant.erasure_completed`: destructive tenant deletion completed.
+
+Legacy audit actions such as `tenant.updated`, `tenant.retired`, and
+`tenant.destroyed` can still be emitted for compatibility. New module behavior
+should key off the explicit lifecycle events above.
+
+Lifecycle event details use concrete tenant identifiers plus optional actor,
+reason, count, and mode information. Destructive erasure is only emitted after
+the tenant row is successfully scheduled for deletion in the same transaction.