optimistic_lock_retries_total counts every claim as at least one retry

This metric is one half of the README's own headline deliverable: the benchmark comparing the two locking strategies reports a "retry rate" computed from this counter. If every successful, zero-contention claim is counted as at least one retry, the reported retry rate is inflated across the board -- an operator deciding whether to switch LOCK_STRATEGY based on "how much contention is the optimistic strategy actually seeing in production" would be working from a number that's wrong even under perfectly healthy, uncontended traffic.

optimistic_lock_retries_total increases by the full attempt count on every optimistic claim -- including claims that succeeded on their very first try, which should contribute nothing.

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

OptimisticAttempts(n) is called once per Claim call with the total number of attempts it made. It currently adds n unconditionally whenever n >= 1 -- which is every single call, since n is never 0. It should only add n - 1, and only when n > 1.

Compare the guard condition and the value passed to .Add(...) in OptimisticAttempts against its own doc comment on the struct field (optimisticRetries) two lines above it, which already states the intended semantics.