Stuck card auth holds after POS declinesCards & Interchange

Task prompt

CX has escalated a run of complaints: a customer's card gets declined at the register, but the money is still held on their account and never comes back. Engineering ticket ENG-252 covers the same pattern — merchant auth holds that the processor claims it released but that still show as applied. Read it first for context. Work out from the card event log how often this is actually happening and what it is costing customers. Each case is a single real transaction event; log rows that are not tied to one are not cases. A case only counts if the same transaction event shows both an authorization hold — an approved row carrying a positive amount_in_cents — and a point-of-sale decline, which shows up as a denied row. Where a transaction event carries more than one approved row, the hold is the size of the authorization, not the total of the rows. A release shows up as a received row on that same transaction event, and only a release tied to that event counts. Anything released more than 24 hours after the authorization is a late release, not a clean one — count those separately from holds that are still open today. Give me: how many transactions had a hold placed and were still declined; how many of those are stuck, meaning still open or released late; how many distinct customer accounts that touches; the dollars still frozen right now; how many holds need a compensating release; the dollars that were frozen but eventually released late; and the first and last dates of the affected window. When you've got it: open a Slack channel called "stuck-card-auth-holds-audit", post a summary with the stuck-hold prevalence, frozen cents and the event window and pin it; file a Bank Operations ticket titled "Stuck card auth holds after POS declines audit"; and reply with declined_with_hold_count, stuck_count, stuck_account_count, frozen_cents, release_needed_count, late_released_cents, event_window_start, and event_window_end.