feat: tombstoning for threat models and sub-entities

[ericfitz]

• allows recovery from accidental deletion
• tombstones must be cleaned up after a time
• tombstones must be immediately removed during user deletion
• need a recovery API

[ericfitz]

Remaining Work — Behavioral Summary

The core tombstoning (soft delete with deleted_at timestamps, cascade to children, include_deleted filtering, background purge) shipped in 3e2f9111. Three items remain:

1. Recovery API

• Owners can restore a soft-deleted threat model. Restoring a threat model automatically restores all of its soft-deleted children (diagrams, threats, assets, documents, notes, repositories).
• Owners can also restore individual sub-entities (e.g., a single diagram that was independently deleted) as long as the parent threat model is not itself deleted.
• Attempting to restore a sub-entity whose parent threat model is also deleted returns a 409 Conflict — the user must restore the threat model first (which cascades to all children).
• Restoring an entity that is not currently deleted returns a 409 Conflict.
• Restoring a non-existent entity returns 404.
• Only users with the owner role on the threat model (or administrators) can perform restores.
• Each restore operation is recorded in the audit trail.

2. Tombstone Cleanup During User/Group Deletion

• Tombstoned threat models are always permanently deleted when their owner's account is deleted, even if an alternate owner exists. The reasoning: the original owner already chose to delete the threat model, so transferring a tombstone to a new owner is not useful.
• Active (non-tombstoned) threat models continue to be transferred to alternate owners as before.
• The same logic applies when a group that owns threat models is deleted: tombstoned threat models owned by the group are permanently removed rather than retained.

3. Background Purge — Metadata and Audit Cleanup

• The existing background purge already permanently removes expired tombstones (entities soft-deleted longer than the retention period, default 30 days).
• Currently, when orphaned sub-resources are purged (soft-deleted children whose parent was not deleted), their associated metadata and audit trail entries are left behind. This will be fixed so that purging an orphaned sub-resource also cleans up its metadata and audit history.