[Feature] keep filename and checksum in the asset deletion audit (tombstone)

[hmnijp]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature - keep filename and checksum in the asset deletion audit (tombstone)

Summary

When an asset is permanently deleted, Immich keeps only a minimal tombstone in
asset_audit (id, assetId, ownerId, deletedAt) plus album_asset_audit
(albumId, assetId, deletedAt). All identifying metadata is removed:
originalFileName, checksum (SHA1), originalPath, type. As a result it is
impossible to reconstruct what was deleted — only that something was removed,
when, and from which album.

Motivation / use case

Self-hosters who curate their library (duplicate review, album pruning, bulk
delete) need a durable audit trail:

• know exactly which files were removed (filename) and their content checksum;
• cross-check against backups / other copies and confirm nothing was lost by
  accident;
• verify provenance/integrity after the fact.

Today, once the trash retention expires (or when deleting directly/permanently),
that information is gone, making any post-mortem impossible.

Current behavior

• Soft delete (trash): the row stays in asset with status='trashed',
  deletedAt set; the file remains on disk; restorable.
• Permanent delete: rows in asset, asset_exif, asset_file, etc. are
  removed and the files are deleted from disk; only asset_audit /
  album_asset_audit tombstones remain, with no name/checksum/path.
• asset_audit is already exposed via the audit API used by client sync, but
  carries no asset identity.

Proposed solution

Persist identity in the deletion record, e.g. add to asset_audit:
originalFileName, checksum, originalPath, fileCreatedAt, type
(or a dedicated asset_history table capturing a snapshot on delete).
Optionally:

• expose it via API / admin UI / CSV export;
• make retention configurable (keep forever by default or N days).

Alternatives considered

• External inventory snapshots (works today, but every admin must build it, and
  it is coarser — daily granularity).
• Longer trash retention (helps temporarily, but is not a permanent record and
  permanent/force delete bypasses it).

Additional context

Privacy trade-off: retaining deleted filenames could conflict with
"right to be forgotten" expectations. A reasonable design could be an opt-in
admin setting, or storing a hash-only record by default with an option to keep
full names.

Observed on a self-hosted instance: 657 permanent deletions produced 657
tombstones with only asset_id + timestamp — no way to tell which files they
were, even though the corresponding rows existed moments before.

Environment

• Immich server: v3.x (Docker), PostgreSQL
• Single admin, self-hosted

Platform

• Server
• Web
• Mobile