Code Review Bench PR #24159 - chore: [Booking Cancellation Refactor - 2] Inject repositories and use them instead of Prisma in cancellation flow

[tomerqodo]

Code Review Bench PR calcom#24159

Original PR Title: chore: [Booking Cancellation Refactor - 2] Inject repositories and use them instead of Prisma in cancellation flow
Original PR Description: ## What does this PR do?

This PR refactors the booking cancellation flow (handleCancelBooking.ts) to use the repository pattern with dependency injection instead of direct Prisma client usage. This is part of a broader architectural improvement to make the codebase more modular and testable.

Key Changes:

• Replaces direct Prisma calls with repository method calls in the cancellation flow
• Adds new repository modules for booking attendees, booking references, and profiles
• Implements dependency injection for the BookingCancelService
• Maintains backward compatibility with fallback to direct Prisma usage during transition

Repositories Added/Modified:

• PrismaBookingAttendeeRepository - handles attendee deletion operations
• BookingReferenceRepository - handles booking reference cleanup
• ProfileRepository - handles profile lookups
• BookingRepository - extended with cancellation-specific methods

Updates since last revision

• Fixed duplicate onBookingCancelled call - Removed an accidental duplicate call to bookingEventHandlerService.onBookingCancelled() that was introduced during merge conflict resolution. The audit event is now correctly triggered only once per booking cancellation.

How should this be tested?

Environment Setup:

• Standard Cal.com development environment
• PostgreSQL database with test data

Test Scenarios:

1. Regular booking cancellation - Cancel a standard one-time booking
2. Recurring event cancellation - Cancel future instances of recurring bookings
3. Seated event cancellation - Cancel bookings with multiple attendees per slot
4. Team booking cancellation - Cancel bookings involving team members
5. Integration cleanup - Verify calendar events and references are properly deleted

Expected Behavior:

• All cancellation flows should work identically to before the refactor
• Database state should be identical after cancellation operations
• External calendar events should be properly removed
• Workflow reminders should be cleaned up
• Booking references should be deleted

Critical Review Areas

⚠️ High-risk areas requiring careful review:

1. Repository method implementations - Verify that each new repository method exactly replicates the original Prisma behavior, including:

   • Return types and data structure
   • Error handling and exception cases
   • Query filters and conditions

2. Transaction behavior - Ensure the repository abstraction doesn't break any implicit transaction boundaries from the original code

3. Conditional logic simplification - The PR changes from uid ? { uid } : { id } to always using bookingToDelete.uid - verify this is safe for all booking types

4. Dependency injection setup - Review the module bindings and ensure all dependencies are correctly wired

5. Fallback path consistency - The code maintains dual paths (repository vs direct Prisma) - ensure they remain in sync

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

---

Link to Devin run: https://app.devin.ai/sessions/469183c6bfa54d5d8f4b69873c2e8b6a
Requested by: @hariombalhara
Original PR URL: calcom#24159