Side-effect orchestration for counter broadcasts — extracted from the prior AshDispatch.Changes.BroadcastCounterUpdate module.

Why this exists separately from the notifier

AshDispatch.Notifier is a thin adapter that pattern-matches the notification's action and looks up per-action config. The actual counter logic — recipient resolution (relationship-based, filter- based, MFA-based), query execution with scoping/filtering, and the configured counter_broadcast_fn invocation — lives here. This isolates the "what to broadcast" decisions (Notifier) from the "how to broadcast" orchestration (CounterHandler).

Preserved verbatim from the prior change module

The recipient resolution, query construction, scope-expression application, filter-by-record, and broadcast invocation logic is carried over unchanged from Changes.BroadcastCounterUpdate. The ONLY behavioural change is when this code runs: it used to fire via Ash.Changeset.after_action/2 synchronously inside the action's transaction; it now fires from Ash.Notifier.notify/1 post-commit (or is dropped on rollback).