Add guest management functionality to existing bookings

Hi there 👋

This PR introduces guest management functionality to existing bookings, allowing organizers to add attendees to already-scheduled events. The implementation covers a new addGuests mutation, email notifications for added guests, and UI components for selecting guests. While the feature direction is reasonable, the implementation introduces several bugs and quality issues that need attention before merging. The most significant issues include: (1) the email blacklist check is case-sensitive, allowing uppercase email variants to bypass the block, (2) the team admin/owner permission check uses && instead of ||, incorrectly denying team admins who are not owners, (3) credential fetching uses the authenticated user instead of the booking organizer, leading to wrong calendar credentials being used for calendar invites, (4) the original (unfiltered) guests array is passed to email sending instead of only the newly added unique guests, causing existing guests to receive duplicate notifications, and (5) missing checks for event type email disable flags in the notification system.

These might need a close look

• 🔴 packages/trpc/server/routers/viewer/addGuests.handler.ts (L46)
  CRITICAL: Permission check uses isTeamAdmin && isTeamOwner (AND) instead of || (OR), incorrectly denying team admins who are not also owners. Only team owners can add guests, which contradicts the intended access model.
• 🔴 packages/trpc/server/routers/viewer/addGuests.handler.ts (L161)
  CRITICAL: getUsersCredentials(ctx.user) uses the authenticated user instead of the booking organizer. This means the wrong user's calendar credentials are used to set up calendar invites for the new guests, potentially leaking or misrouting calendar events.
• 🔴 packages/trpc/server/routers/viewer/addGuests.handler.ts (L168)
  BUG: The original (unfiltered) guests array is passed to sendAddGuestsEmails, but only uniqueGuests was persisted. Existing guests receive notifications as if they were newly added.
• 🔴 packages/emails/email-manager.ts (L522)
  BUG: sendAddGuestsEmails does not check eventTypeDisableHostEmail or disableAttendeeEmail flags. Guests may receive notifications for bookings where the organizer has explicitly disabled email notifications.
• 🔴 AddGuestsDialog.tsx (L68)
  BUG: Error message display is fragile: err.data?.code can be undefined, resulting in "undefined: message" being shown to the user. Use a fallback string for the error code.

Worth checking

• 🟡 packages/trpc/server/routers/viewer/addGuests.handler.ts (L92)
  Guest attendees are created with name: "". Empty names appear in email templates and UI, creating a poor experience for the added guests. Default to the email address or a placeholder.
• 🟡 packages/trpc/server/routers/viewer/addGuests.schema.ts (L5)
  Schema does not enforce uniqueness of the input guests array. createMany can insert duplicate guest rows if the same email appears multiple times. Add a .refine() for uniqueness.
• 🟡 AddGuestsDialog.tsx (L18)
  Zod schema is duplicated locally in the dialog component instead of importing from the TRPC router definition. This creates a maintenance risk if the server schema changes and the local copy is not kept in sync.
• 🟡 AddGuestsDialog.tsx (L41)
  isInvalidEmail state variable is never reset when the input changes. If a user enters an invalid email then corrects it, the invalid email error persists.
• 🟡 AddGuestsDialog.tsx (L28)
  multiEmailValue starts with [""] causing validation errors on an empty form. Initialize with [] instead.
• 🟡 MultiEmailLazy.tsx (L4)
  Double type assertion (as unknown as ...) in Next.js dynamic import is unsafe and can mask type errors at build time. Use a proper type assertion or refactor the import pattern.
• 🟡 packages/emails/email-manager.ts (L540)
  New guests receive an "event scheduled" email template instead of an "added to existing booking" template. This is misleading and inconsistent with the actual action performed.
• 🟡 packages/emails/organizer-add-guests-email.ts (L30)
  Email subject uses attendees[0].name which may be empty (guests are created with name: ""), resulting in empty or malformed subject lines.
• 🟡 packages/features/bookings/components/BookingListItem.tsx (L192)
  "Add guests" action is shown for past bookings, which is semantically invalid — you cannot add attendees to an event that has already occurred. Filter by booking date.
• 🟡 packages/features/bookings/components/BookingListItem.tsx (L192)
  Missing disabled prop for loading state, which allows concurrent mutations via the "Add guests" button while a request is in flight.
• 🟡 packages/features/bookings/components/BookingListItem.tsx (L192)
  No frontend permission check before showing the "Add guests" action. Unauthorized users can see the action even if they don't have permission to execute it.

Small things (take or leave)

• 🔵 addGuests.handler.ts (L57)
  Fragile booking.eventType?.teamId ?? 0 can produce wrong team check when teamId is 0 (a sentinel value). Use a distinct sentinel or explicit null check.
• 🔵 MultiEmail.tsx (L35)
  value = value || [] mutates the prop directly, which is a React anti-pattern. Use a local variable or state instead.
• 🔵 MultiEmail.tsx (L43)
  Array index used as React key, which can cause state mismanagement when items are reordered or filtered.
• 🔵 organizer-add-guests-email.ts (L33)
  Prop named attendee is misleading when it actually contains the organizer object. Rename to clarify the intent.
• 🔵 OrganizerAddGuestsEmail.tsx (L7)
  callToAction={null} is fragile if the order of props changes in the component signature. Use a dedicated prop or restructure to avoid positional fragility.