Transactional webhook event persistence and Oban job dispatch (D2-24).

All three writes (webhook_event row, Oban job, accrue_events ledger entry) succeed atomically or none do. Duplicate POSTs are idempotent via the UNIQUE(processor, processor_event_id) constraint with on_conflict: :nothing.

Transaction shape

Ecto.Multi
|> run(:persist, ...)           # check-then-insert with on_conflict guard
|> run(:maybe_enqueue, ...)     # Oban job only for new events
|> run(:maybe_ledger, ...)      # accrue_events only for new events

Duplicate detection uses an explicit SELECT-then-INSERT pattern inside a single Multi.run step. The on_conflict: :nothing guard on the INSERT handles the race condition where a concurrent request inserts between SELECT and INSERT. With binary_id autogenerate, Ecto generates UUIDs client-side, so the Pitfall 2 approach (id: nil on conflict) does not work -- the struct always has an id regardless of conflict.