fix(security): separate booking and check-in tokens

docs/booking-flow.md

@@ -25,7 +25,7 @@ Availability shown to visitors is informational. The backend recalculates availa
    - requested seats do not exceed currently available seats.
 6. The backend creates a `pending` reservation.
 7. The backend creates a random opaque confirmation token.
-8. The backend sends an email with a confirmation link.
+8. After the transaction commits successfully, the backend sends an email with a confirmation link.
 9. The frontend tells the visitor to check their email.
 
 The reservation is not confirmed at this stage.
@@ -45,8 +45,8 @@ The reservation is not confirmed at this stage.
 6. The backend recalculates confirmed reservations for the performance.
 7. The backend confirms the reservation only if enough seats remain.
 8. The backend marks the confirmation token as used.
-9. The backend creates a QR verification token.
-10. The backend generates a QR code containing the opaque QR token or a verification URL.
+9. The backend creates a separate `check_in` token for QR verification.
+10. The backend generates a QR code containing only the opaque check-in token or a verification URL built from that token.
 11. The backend returns or sends the QR code to the visitor.
 
 If there is no longer enough capacity, the backend must not confirm the reservation.
@@ -111,7 +111,7 @@ This operational flow should still follow the same backend rules as the public b
 2. the backend validates booking availability and capacity;
 3. the backend creates a `pending` reservation;
 4. the backend creates the normal confirmation token;
-5. the backend sends the standard confirmation email;
+5. after the reservation transaction commits, the backend sends the standard confirmation email;
 6. the guest still confirms through the email link before the reservation becomes confirmed and usable for check-in.
 
 ## Duplicate Check-In