Single notifier that handles ALL DispatchEvent and counter-broadcast work for resources using the AshDispatch DSL.

Why this lives here

AshDispatch's prior approach registered per-action change modules via Ash.Changeset.after_action/2, which fires synchronously inside the action's transaction BEFORE commit/rollback. Wrapping a dispatch-emitting action in Ash.transaction/2 therefore allowed phantom dispatches and counter increments to broadcast for rows that subsequently rolled back.

Routing through Ash.Notifier instead inherits Ash's commit-deferred semantics for free: notifications accumulate in Process.put(:ash_notifications, …) and fire post-commit, or are dropped on error (see deps/ash/lib/ash.ex:3917-3970 in the consuming Mosis app for the defer-and-fire-or-drop trace).

Registration

Resources don't register this notifier directly. The transformers AshDispatch.Resource.Transformers.InjectDispatchChanges and AshDispatch.Resource.Transformers.InjectCounterBroadcasts persist per-action config into the resource's dsl_state AND append this module to :simple_notifiers (mirroring the existing InjectEntityNotifier pattern at line 38 of that transformer).

Per-action config lookup

Per-action event_config and counter_config data — formerly embedded as change_opts in the change tuple — is now persisted via Spark.Dsl.Transformer.persist/3 and read back via AshDispatch.Notifier.Info. This mirrors Ash.Notifier.PubSub's approach: a single notifier with a Spark Info module reading per-action config (per Ash.Notifier.PubSub.Info.publications/1).

Side-effect orchestration

The actual dispatch and counter-broadcast logic is preserved from the prior Changes.DispatchEvent and Changes.BroadcastCounterUpdate modules — moved to AshDispatch.Notifier.DispatchHandler and AshDispatch.Notifier.CounterHandler and called from notify/1. Only the registration point changed; all downstream Dispatcher / EventResolver / ChannelResolver collaborators stay unchanged.