Optimistic-concurrency check silently removed from UpdateState

This is the single mechanism that makes it safe for a webhook confirming a capture and an auto-void timeout to race each other without corrupting data -- the entire "optimistic concurrency" story the README documents as a core guarantee. Without it, whichever of two concurrent writers commits last simply overwrites whichever committed first, silently. In payment terms: a merchant's capture request and an internal auto-void timeout racing at nearly the same instant could both report success, with one of them's effect vanishing without a trace, no error logged anywhere, no 409 Conflict ever returned.

Store.UpdateState's UPDATE statement no longer has AND version = $expectedVersion in its WHERE clause -- only WHERE id = $X. A caller holding a stale version can still successfully overwrite the row.

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket20 -v -count=5

The natural "fire two truly concurrent, conflicting ApplyEvent calls" test (TestService_ApplyEvent_Conflict_OnlyOneOfTwoConcurrentEventsApplies) still passes even with this bug present, 5/5 runs -- not because the bug doesn't exist, but because a plain UPDATE always takes a row-level lock regardless of its WHERE clause, so the two transactions still serialize on that lock, and the second one often fails machine.Fire's own validity check before it ever reaches UpdateState at all. This ticket's test instead reproduces the exact condition deterministically: read a payment, have some other write bump its version behind its back, then call UpdateState with the now-stale version directly.

Real concurrency bugs are notoriously hard to pin down with timing-dependent tests -- this is exactly why the project ships a deterministic test alongside its own timing-dependent one for this exact code path.

Compare UpdateState's current WHERE clause against what its own doc comment says it does ("guarded by WHERE version = expectedVersion"). The expectedVersion parameter is still there -- it's just no longer used in the SQL.