Automatic cleanup of dormant vaults with warn-before-purge

Summary

Add a GDPR data-minimization feature: detect vaults that have gone unused, warn the owner ahead of time, and then crypto-erase the dormant vault. The goal is to not retain a citizen sensitive documents forever once they stop using the service, while never purging without a clear warning and a chance to act.

What exists today (and why it is not this)

• GarbageCollector reaps authorization hygiene only (expired grants and trusts, abandoned consent requests); it never touches vault contents.
• Vault::purgeUser crypto-erases a vault, but it fires on Drupal account deletion (account-driven, no warning), not on inactivity.

So the erase primitive already exists; what is missing is the dormancy lifecycle around it.

Define "unused" by last vault activity

Dormancy is measured by a per-owner, per-tenant last_activity timestamp, updated whenever the owner connects to the vault site: the current tenant's value if the current tenant can be determined, otherwise every tenant's.

Lifecycle

1. Detect dormancy: a cron pass finds vaults whose last_activity is older than a configurable threshold.
2. Warn the owner: send escalating notifications (email) ahead of the purge, with a clear deadline and a way to keep the vault: reactivate (any vault activity resets the clock) or download their documents first.
3. Crypto-erase: after the grace period with no reactivation, destroy the Subject KEK (the existing O(1) crypto-erase), then clean up the now-unreadable rows.

Safety rails

• Configurable thresholds (dormancy age, warning lead time, number of reminders), with defaults that err toward warning rather than erasing.
• A dry-run or preview (which vaults would be warned or purged) before anything destructive runs.
• Crypto-erase first, bounded per cron run; never a single blanket sweep.
• Every step recorded in the audit trail (dormancy detected, warned, reactivated, erased).
• Operator opt-in: the feature stays off unless a threshold is configured, so no site silently starts deleting data after an upgrade.

Multi-tenant interaction

Dormancy must be per vault, not per account: a citizen may use one tenant vault and not another, so only the dormant tenant vault is warned and purged. Depends on the multi-tenant work in #3593589: Multi-tenant support: per-tenant Master KEK and pluggable tenant resolution (per-(tenant, owner) Subject KEK and last_activity). Until that lands, dormancy is per owner.

Notifications and delivery

pdv dispatches a domain event at each lifecycle step (dormancy detected, warning due, final notice, erased) and ships a default email built on Symfony Mailer (already the site transactional mail layer). Richer or multi-channel delivery (an in-site message, an owner-dashboard banner, SMS, or per-user channel preferences) is left to optional integration, for example ECA reacting to the events, or the Message stack or Courier, so pdv core takes no notification-framework dependency.

Open questions

• Default thresholds (for example warn at 18 months, erase at 24), to be set conservatively and documented.

Tests

• A vault past the dormancy threshold is detected; one within it is not.
• Any vault activity resets last_activity and cancels a pending purge.
• Warnings are sent on schedule; the purge runs only after the grace period with no reactivation.
• Purge crypto-erases (Subject KEK destroyed, contents unreadable) and is bounded per run.
• With the feature unconfigured, nothing is ever warned or purged.
• Each lifecycle step writes an audit-trail event.