Open-order supersede skips the buyer's own already-lapsed hold on the same window; the stale PENDING row and its tentative slot wait for the abandoned-payments sweep

[teetangh]

findReusablePendingOrderPayment (lib/payments/operations/checkout.ts, the candidate query) gates on expiresAt > now, by design ("never resume a stale hold"). A buyer who returns to the exact same slot after their 30-minute window lapsed therefore gets a fresh order (correct), but the lapsed row is never a candidate, so it is neither resumed nor superseded, and releaseSupersededHolds (#1465) does not run for it. The old Payment stays PENDING and its tentative slot rows stay SCHEDULED until the abandoned-payments sweep (the Netlify ticker runs it every 5 minutes in production).

Nothing is blocked or double-charged in the interim: buildDeadHoldFilter already treats the lapsed hold as dead for availability, which is why the new order mints. The cost is a stale tentative row on the consultant's calendar and an unresolved PENDING payment for up to one sweep cycle.

Suggested fix: when the self-hold lookup (findSelfHoldAppointmentIds) finds the buyer's own hold on the exact window whose payment has lapsed, release it through releaseSupersededHolds in the same request (same CAS, same transition helpers) before minting the new order. Keep the freshness gate for resume.

Evidence: wave 3 on deploy-preview-1422 (union ff7cf5d), Payment 5d4dd778-4eef-44e0-b9bc-be9ea81fcfde backdated by SQL, second POST minted order_TYIKJ3UB3LCva1 while the old row stayed PENDING with slot 84e49b8e-072b-4658-b955-0cffc16d4ddc SCHEDULED. The wave's report also claimed the supersede block only flips the payment status; that is wrong on dev — releaseSupersededHolds releases slots and parent requests for fresh-but-mismatched candidates.

[teetangh]

Verdict 2026-09-05 (booking closure pass, dev 9dc665a). Diagnosis confirmed on current code. findReusablePendingOrderPayment still carries expiresAt: { gt: new Date() } (lib/payments/operations/checkout.ts:353), so a lapsed hold enters neither the reusable nor the supersede set and releaseSupersededHolds (:3248) is never reached for it; findSelfHoldAppointmentIds (:1107) is liveness-only by construction (:1053-1071). Nothing is blocked or double-charged meanwhile because the dead-hold filter frees the window. Fix shape: a third, narrow lookup for the buyer's own dead hold on the exact window/plan/gateway/org, fed into the existing releaseSupersededHolds before minting, leaving the resume path's freshness gate untouched. S–M, no schema. Post-MVP as labelled.