Outbox dispatcher can claim the same due row twice under concurrency

This is the exact "many replicas must not double-fire the same due work" guarantee the README calls out as this project's reason for running two app replicas by default. Without it, two dispatcher replicas polling at the same moment can both claim and dispatch the SAME outbox row -- meaning the bank/UPI rail can receive two genuinely concurrent, redundant calls for what should be a single side effect. A real bank/UPI integration that isn't perfectly idempotent under true concurrent calls would be exposed to a genuine double-charge risk.

SelectDueIDs's query is missing FOR UPDATE SKIP LOCKED. A second, concurrently-open transaction's identical due-work query can return the same row(s) a first transaction has already selected, even though the first hasn't committed or written anything yet.

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket21 -v -count=5

A genuinely concurrent, goroutine-based test turns out to be too timing-dependent to reliably trigger this in practice, so this ticket's test instead drives outbox.SelectDueIDs from two manually-sequenced transactions, deterministically opening the race window: transaction B runs the same query while transaction A has already selected the row but not yet committed.

Compare SelectDueIDs's SELECT against internal/timeout/sweeper.go's claimDue, which does the equivalent claim for payment timeouts, for the exact clause that's missing here.

Compare SelectDueIDs's SELECT against internal/timeout/sweeper.go's claimDue, which does the equivalent claim for payment timeouts, for the exact clause that's missing here.