ResumeStuckProcessing resumes the wrong rows

This function is the crash-recovery safety net documented in the project's own README: "an instance dies while a row is claimed -> ResumeStuckProcessing, called by every replica at startup, requeues any row left processing past a grace window." With the comparison inverted, that safety net does the opposite of its job on both sides at once: it steals rows a healthy, currently-working replica legitimately has in flight (risking a real duplicate bank call under just the wrong timing), and it leaves genuinely crashed rows stuck processing forever -- exactly the "a payment silently gets lost in limbo after a crash" scenario the whole outbox design exists to prevent.

ResumeStuckProcessing(ctx, olderThan) requeues rows whose updated_at is more recent than olderThan ago (i.e., recently claimed, likely still legitimately in flight) and leaves alone rows older than that (i.e., genuinely stuck).

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket17 -v

This also collaterally breaks the project's own TestDispatcher_ResumeStuckProcessing_RequeuesCrashedRow (in internal/outbox/dispatcher_test.go).

Look at the SQL in ResumeStuckProcessing: WHERE status = 'processing' AND updated_at <comparison> now() - $1::interval. The comparison operator determines which side of "how long ago" counts as stale.

Think through what "older than olderThan" means in terms of a timestamp comparison against now() - olderThan: is a row whose updated_at is before that cutoff the old one, or the recent one?