Concurrent commit/release calls on the same reservation can both apply

This is the mechanism the README explicitly credits for making commit idempotent under real concurrency: "the FOR UPDATE row lock on the reservation serializes concurrent commit calls for the same id." Without it, two callers racing to resolve the same reservation -- a retried payment webhook and a manual support action landing at the same instant, or two webhook deliveries from a payment provider's own at-least-once retry policy -- can both read status: active before either has written anything, and both apply their own transition. For two concurrent commits, that means sold incrementing twice for a single reservation: a real double-sell of the same unit, silently, with no error to anyone.

LockReservation's SELECT is missing FOR UPDATE. A second, concurrently-open transaction locking the same reservation id does not wait for a first, still-open transaction -- it proceeds immediately.

1. go test ./tickets/tests/... -run TestTicket25 -v

Unlike ticket-24's SKIP LOCKED (which never blocks), plain FOR UPDATE does block -- so genuinely proving this requires observing that blocking behavior, not just counting how many times something got double-applied under real goroutine timing. This ticket's test drives LockReservation (exported, and the exact function resolve itself calls) from one transaction held open in the main goroutine and a second one attempted in a background goroutine, and asserts directly on the blocking.

Compare LockReservation's SELECT against SelectDueReservations in pkg/inventory/reaper.go (ticket-24, right next door) -- both are claiming queries, but this one needs FOR UPDATE alone (block and wait, since a resolve should still eventually run once the first one finishes), not FOR UPDATE SKIP LOCKED (skip and move on, which is right for a reaper's batch poll but wrong here).