Consider auditing for Tenant deletion

When a tenant is fully deleted it's just all removed from the DB. For a in-use tenant that's a pretty "serious" operation so we can think about what auditing could be done to track if that happens, help with recovery if it's a mistake, and keep records for security incidents.

There would be existing log statements (at least just from the REST endpoint call) so there could be some tracking with Grafana as well?

But without relying on logging we could consider an Innkeeper audit table against the Innkeeper tenant that keeps track of these actions (as well as things like tenant creation, "make-issuer" allowance, etc)

As another feature on top of auditing we should probably have (at least for "normal" operational usage) emailing functionality when the delete is done through the Tenant UI (which is the only way real operators of Traction should be doing it anyways). Dispatch an email to the Innkeeper inbox about a deletion. Possibly can use the Tenant email on file to inform about deletion as well?
Consider if this should be done on suspension (soft-delete) too?

Start by tracing the REST tenant-deletion endpoint and the Tenant UI path, then review the existing log statements mentioned in the issue. Clarify whether the scope includes an Innkeeper audit table, recovery support, Grafana tracking, deletion emails, and suspension events; done requires an agreed design and implementation scope for these actions.

Written by the indexing model from the issue text.