The booking API accepts a skipEmail flag so post-checkout consultations do not send duplicate confirmations

The booking API at api/book/route.ts accepts a skipEmail boolean in the request body. When skipEmail is true, the confirmation email does not send, even though the booking is still created in Google Calendar and the response still includes the Meet link and times. The flag exists because of the checkout flow. When a client buys a fixed-price package, the Stripe webhook fires and sends a purchase confirmation email with the order details. The checkout confirmation page then renders a ConsultationPicker component where the client can book a follow-up consultation. That booking request passes skipEmail set to true. Without the flag, the client would receive two emails in quick succession — one for the purchase, one for the consultation — and the second would feel redundant because the calendar invite already arrives from Google. The sidebar BookCall component never sets skipEmail, so 15-minute calls from the service pages always send a confirmation. The API does not know about Stripe. It does not check whether a payment preceded the booking. It accepts a boolean and the caller decides. The checkout confirmation page knows it already sent an email. The service page sidebar knows it did not. One parameter, two calling contexts, zero coupling between the booking system and the payment system.