Dead-letter outbox replay endpoint

Once an outbox row exhausts OUTBOX_MAX_ATTEMPTS and is marked dead, there's no way to give it another shot short of manual database surgery (UPDATE outbox SET status = 'pending', attempts = 0 WHERE id = ...) -- exactly the kind of thing that turns a 2-minute incident response into a "who has prod DB access and is awake right now" scramble.

The route (POST /v1/payments/{id}/outbox/{outboxID}/replay), handler, and error mapping (outbox.ErrOutboxRowNotFound -> 404) all exist; Dispatcher.ReplayDeadLetter itself is a panicking stub.

go run ./cmd/paystate curl -s -X POST localhost:8080/v1/payments/<id>/outbox/<outboxID>/replay

-> 500 Internal Server Error, panic logged: Dispatcher.ReplayDeadLetter not implemented

This needs a somewhat careful WHERE clause: id = $1 AND payment_id = $2 AND status = 'dead'. All three predicates matter -- the id alone isn't enough (a caller could try to replay a row belonging to a different payment via the URL's {id}), and the status check matters because replaying a row that's pending/processing/processed would be a correctness bug (double-dispatching a row that's about to be or already was handled normally), not a feature.

Look at Store.UpdateState's pattern of using RowsAffected() to detect "did my WHERE clause actually match a row" (in internal/payment/store.go) for the shape you need here: run the UPDATE ... WHERE id = $1 AND payment_id = $2 AND status = 'dead', and if RowsAffected() == 0, return ErrOutboxRowNotFound (declared right above ReplayDeadLetter) rather than treating it as success.