Notification convention: modules emit events, the site delivers (no per-module notifier)

Summary

Establish a shared convention across this module family (pdv, audit_trail, webdav, and their bridges) for notification-worthy events, so no module reimplements its own notification mechanism. The principle: a module owns what happened and dispatches a well-named event; how to notify (channels, templates, per-user preferences, throttling) is the site job, handled once by a shared delivery layer.

Why

Drupal core has no single notification API, so the path of least resistance is for each module to hand-roll hook_mail plus token replacement, and every module rebuilds the same delivery and preferences plumbing. That duplication is what this convention avoids: consolidate the shared behavior in one consumer rather than copying it across modules.

The convention

• A module dispatches a domain event for each notification-worthy moment, named consistently (for example pdv vault.dormancy_warning_due, audit_trail chain_verification_failed), carrying a stable documented payload (subject, context ids, severity, a render-safe summary) and no PII beyond what a downstream handler needs.
• A module does not deliver notifications itself: no bespoke hook_mail notifier, no per-module channel or preference handling.
• Delivery is configured once at the site level against those events. The recommended mechanism is ECA (event-driven, no-code: map an event to a channel and template), with the Message stack or Courier as alternatives when stored messages or per-user channel preferences are wanted. Symfony Mailer is the templated email layer underneath.
• A module may ship a minimal default (a plain email via the mail manager) so it works out of the box, but that default is overridable and never a second delivery framework.

Scope

Applies to pdv (and pdv_client and the audit bridges), audit_trail (and audit_trail_webdav and audit_trail_tsa), and webdav. Concrete consumers already on the table: the dormant-vault warnings and the "your export is ready" message from the owner vault export.

Deliverables

• A short documented event-naming and payload convention.
• An audit of where each module currently sends or would send notifications, and a plan to route them through events.
• Optionally, example ECA models (event to email) shipped as documentation, not as a dependency.

Open questions

• Where the convention is documented (a shared page versus per-module docs).
• Whether to provide a tiny shared event base or interface, or keep each module independent and align by convention only (leaning toward convention only, to avoid a shared dependency).