Fixes the two issues Greptile raised on #2478. Both are valid; only one of the prescribed remedies actually works, and this PR says why.

Issue 1 , non-atomic scheduled-send claim (queue-handler.ts)

Valid, fixed properly. The worker read pending_emails_status and then sent , check-then-act over a store that cannot make the pair exclusive. KVStore (runtime/platform.ts) is get/put/delete with no compare-and-swap, which is why the guard's own comment already called itself "best-effort, not a CAS". Two real consequences: cancel-on-reply writes cancelled into the gap and the email goes out after the reply that was meant to stop it; and two deliveries of the same message (SQS is at-least-once, and the cron re-enqueues on a failed KV delete) both read pending and both send.

The decision moves onto the durable scheduled_sends row this subsystem already has, where one conditional UPDATE … SET status='sending' WHERE status='pending' is atomic. Exactly one caller wins, so delivery and cancellation are mutually exclusive rather than merely ordered. No migration , status is plain text with no CHECK constraint.

Three things make it safe rather than just atomic:

• A missing row means bookkeeping that never landed, not a cancellation , it falls through to the KV guard. Refusing there would turn a lost row into a lost email, inverting the invariant the module is built on.
• A failed delivery releases the claim, because the queue redelivers and a row stuck on sending could never be re-claimed , the retry would skip it silently.
• Cancellation reports whether it won. mail.unsend now returns an error rather than a success the client acts on by deleting the draft behind an email already on its way.

Rows abandoned on sending by a worker that died mid-send are collected by the existing stale sweep.

Issue 2 , orphaning window on conversation delete (conversation-repoint.ts)

Valid, but the prescribed fix does not work , and this is the part worth reviewing.

Greptile asked for "one transaction or lock". A transaction does not close this window. The database runs at READ COMMITTED (verified, not assumed): each statement takes its own snapshot, so a document committed after the check is invisible to the check and untouched by the delete. A transaction buys atomicity, not isolation from concurrent inserts.

Closing it outright needs both sides cooperating , SERIALIZABLE on the writers too, or a lock every writer takes , and documents are inserted from ~10 sites across 6 services. Any such scheme is one missed call site away from silently not working. The real fix is a foreign key, which the path-addressing scheme (conversation/{id}/…, no FK column) cannot express today.

What a single statement does buy is removing the gap between the two operations. DELETE … WHERE NOT EXISTS (…) evaluates the predicate and deletes under one snapshot, so the window shrinks from two round-trips , plus whatever the caller does between them , to the statement's own execution, and anything already committed blocks the delete. repointDocumentsAndDeleteConversation then re-points the straggler and retries, which converges; three rounds without converging is not a race and raises rather than deleting.

All four merge/repair paths route through it, so none issues a bare conversation delete any more.

Residual risk, stated plainly: an insert committing during that one statement's execution can still slip through. Eliminating it is a foreign-key project, not a patch.

Test plan

• 37 new/updated tests, all against real SQL (in-process PGlite), not mocks , the guarantee in both fixes is the SQL predicate, so a mocked db would agree with whatever the implementation asked for and prove nothing.
• The load-bearing one: 8 concurrent claimants, exactly one wins. Also cancelled-first, sent-already, missing-row, wrong-connection, release-and-re-claim, and cancel-loses-to-a-claimed-send.