Challenge 3: Handle a Duplicate Webhook Delivery — Possible Solution
====================================================================

THE FIX: TRACK PROCESSED EVENT IDS
---------------------------------------
Before doing any real work for an incoming webhook, the handler
should check whether the event's id (evt_1Nx8k in this case) has
already been processed — for example, by looking it up in a
database table (or similar store) of "already-handled event ids."

  1. Webhook arrives with id "evt_1Nx8k" (first delivery).
  2. Handler checks: has "evt_1Nx8k" been processed before? No.
  3. Handler processes it normally: sends the confirmation email,
     records "evt_1Nx8k" as processed, and responds 2xx.
  4. The SAME webhook arrives again with id "evt_1Nx8k" (the
     duplicate, caused by the slow first acknowledgement).
  5. Handler checks: has "evt_1Nx8k" been processed before? YES.
  6. Handler SKIPS the actual work (no second email sent) and simply
     responds 2xx again, acknowledging receipt without repeating the
     side effect.

WHY THIS WORKS AS AN ANSWER
------------------------------
The event id is the one piece of information both deliveries share in
common — even though the delivery happened twice, it's still
logically the SAME event, and the id is what lets the handler
recognize that. This mirrors Chapter 4's Idempotency-Key pattern
almost exactly, just from the receiving side instead of the sending
side: there, the CLIENT generated a key to let the SERVER recognize a
repeated request; here, the PROVIDER already generates the event id,
and it's the RECEIVING server's job to use it the same way — as a
deduplication key that prevents a side effect (like sending an email)
from happening more than once for what is really one single event.