ApplyEvent returns a payment one version behind reality

The HTTP API's POST /v1/payments/{id}/events/{event} response is the payment record a client sees immediately after acting on it. If its version field is one behind what's actually stored, any client that implements its own "only proceed if nothing else changed" logic against that version will always think it's acting on stale data one step sooner than it actually is -- every follow-up request looks like a conflict from the client's point of view, or worse, race-condition-shaped bugs downstream that are hard to reproduce because the database is fine, only the response body lied.

After a successful ApplyEvent, the returned *Payment's Version field is the pre-transition version, not the post-transition one -- even though the database was correctly updated.

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket16 -v

This also collaterally breaks the project's own TestService_ApplyEvent_HappyPath (in internal/payment/store_test.go) -- expected, both should pass together once fixed.

applyFireAndPersist reads a payment, computes a transition, and attempts Store.UpdateState(ctx, tx, p, expectedVersion). On success (applied == true), the SQL has already bumped the row's version column by one -- but the in-memory p struct the function goes on to return still holds whatever value it had before that call.

Right after the if !applied { ... } early-return in applyFireAndPersist, is there anything updating p.Version to reflect what was just committed? Compare against what expectedVersion was captured as a few lines earlier, and what the SQL in UpdateState actually does to the version column.