Modified booking sends updated .ics with the same UID and incremented SEQUENCE

RFC 5545 defines SEQUENCE as the mechanism calendar clients use to determine whether an incoming invite supersedes an existing one. When a modified booking is sent without an incremented SEQUENCE, clients that have already processed a SEQUENCE:0 invite ignore or flag the incoming update as stale — the customer's calendar retains the old time and location. The result is a no-show caused not by the customer but by the booking system's failure to follow the standard. Without a sequence column in the database, the increment cannot be persisted across calls, meaning the SEQUENCE will reset to 0 on each modification and every update will be treated as stale.

Add a sequence integer column to the bookings table, increment it on every modification, and pass the stored value to the ICS generator in src/lib/bookings.ts:

async function modifyBooking(bookingId: string, changes: Partial<Booking>) {
  const booking = await db.bookings.findUnique({ where: { id: bookingId } })
  const updated = await db.bookings.update({
    where: { id: bookingId },
    data: { ...changes, sequence: (booking.sequence ?? 0) + 1 },
  })
  const icsData = await generateBookingICS(updated, booking.host)
  await emailQueue.add('send-modification-email', {
    bookingId,
    customerEmail: booking.customer_email,
    icsAttachment: icsData,
  })
}

The generateBookingICS function in src/lib/calendar.ts must read booking.sequence and set it as the SEQUENCE field — not hardcode 0.