Reserving exactly the last unit of stock is wrongly rejected

This project's entire reason for existing, stated plainly in its own README, is "100 units of stock, 50,000 simultaneous clicks, and EXACTLY 100 must succeed." With this bug, the 100th buyer -- the one asking for exactly the last unit of remaining stock -- gets a "sold out" rejection even though there is precisely enough stock to satisfy them. In a real flash sale that is a customer who did everything right and got turned away for no reason, a lost sale, and (if anyone compares "units sold" against "units in the warehouse" afterward) a support ticket asking why inventory does not match what was reported sold.

POST /v1/skus/{id}/reservations for a quantity exactly equal to the SKU's current available returns 409 Conflict ("insufficient stock"), even though there is exactly enough stock.

1. go test ./tickets/tests/... -run TestTicket01 -v
2. Or manually: curl -X POST localhost:8081/v1/skus -d '{"sku_id":"demo","quantity":5}'
3. curl -X POST localhost:8081/v1/skus/demo/reservations -d '{"quantity":5}'
4. Observe: 409, even though exactly 5 were available.

ConditionalStrategy.Claim (the default locking strategy) is a single atomic conditional UPDATE ... WHERE available >= $2. The WHERE clause's comparison operator IS the entire correctness boundary this project is built around -- get it wrong by one character and the "exactly N must succeed" guarantee is violated in the conservative direction (under-selling instead of overselling), which is safer than overselling but is still a real, measurable bug against the documented contract.

Look at the WHERE clause in ConditionalStrategy.Claim and compare it against the comment directly above the struct definition, which already describes the intended behavior ("re-evaluates WHERE available >= qty"). Zero remaining stock after a successful claim is a valid outcome, not insufficient stock.