Idempotency-Key support for POST /v1/payments

POST /v1/payments has no protection against being accidentally called twice for the same logical request (a client's retry after a timeout, a double-tapped "pay" button, a load balancer replaying a request). Every call creates a brand-new payment, full stop -- exactly the kind of gap that turns a network blip into a real double-charge.

A payments.idempotency_key column (migration 000002), the Payment.IdempotencyKey field, the CreateParams.IdempotencyKey field, Store.Insert's wiring to persist it, and the HTTP handler reading the Idempotency-Key request header all already exist. Only Store.FindByIdempotencyKey -- the lookup that turns a retried request into "return what already happened" instead of "create a duplicate" -- is a panicking stub, so Service.Create panics (surfaced as 500) the moment any caller supplies an Idempotency-Key.

go run ./cmd/paystate curl -s -X POST localhost:8080/v1/payments
-H 'Idempotency-Key: abc-123'
-d '{"amount_minor": 1000, "currency": "INR"}'

-> 500 Internal Server Error, panic logged: Store.FindByIdempotencyKey not implemented

This mirrors the exact problem reliable/pkg/idempotency (a sibling project in this repo) solves -- "the same request, sent twice, must produce the same result, not double the effect." Here it's scoped down to a single lookup-before-insert, backed by the partial unique index payments_idempotency_key_idx (WHERE idempotency_key IS NOT NULL) as a last-resort guarantee even if two requests with the same key somehow raced past the lookup at the same instant.

Look at Store.Get right above Store.FindByIdempotencyKey in internal/payment/store.go for the query/scan pattern -- you need the same thing with WHERE idempotency_key = $1 instead of WHERE id = $1, returning ErrNotFound on no match (exactly like Get does), which is what Service.Create already checks for via errors.Is(err, ErrNotFound) to decide "no existing payment, proceed to create" vs. "found one, return it."