Conflict check counts self-authored bookings, blocking subsequent bookings to the same group event

Plugin: Fluent Booking Pro 2.0.05 (with Fluent Booking 2.0.05)
Setup: Group event (Mysore class, max 20 attendees), Google Calendar 2-way sync enabled with that calendar as the “conflict check” calendar.
What’s happening

1. User A books the group event at 06:30.
2. Fluent Booking’s GCal sync writes a corresponding event onto my host calendar (e.g., “Booking: Mysore — Tuesday, Apr 28”).
3. User B tries to book the same group event at 06:30.
4. The conflict check runs GoogleHelper::getRemoteBookedSlots() on my host calendar, finds the event Fluent Booking just wrote there, and treats it as a host-busy conflict.
5. User B is blocked — even though there are 19 spots remaining on the same event.
   So the conflict checker is fighting its own sync. After the first booking, every subsequent booking to the same group event sees a “host busy” event that the booking system itself just created.
   Why I think this is a bug
   The events fluent-booking writes to GCal carry a clear marker (the booking id, plus your sync metadata). The conflict checker doesn’t filter those out — it treats them like any other busy block on the host’s calendar. Result: group events that are explicitly designed to allow N concurrent bookings get gated as if they were 1-on-1 sessions.
   For 1-on-1 events this isn’t visible because max-per-slot is 1 anyway. The bug only surfaces on group events (event_type=group_event, max_book_per_slot > 1), which is exactly the scenario you’d want concurrent bookings to work cleanly.
   Reproduction
6. Create a group event with max_book_per_slot = 20.
7. Connect host’s Google Calendar with 2-way sync, mark that calendar as a conflict-check calendar.
8. Have user A complete a booking.
9. Confirm a “Booking: …” event lands on host GCal.
10. Have user B attempt to book the same slot — they’re blocked, even though remaining = 19.
    Workaround
    Empty conflict_check_ids on the host’s _google_user_token meta (wp_fcal_meta). This disables conflict checking site-wide, so external host events stop blocking bookings — but internal Fluent Booking conflicts still work, which keeps 1-on-1 protection intact. Acceptable temporary fix; not great as a permanent state because the host loses real-conflict protection from their actual personal calendar.
    Suggested fix
    When GoogleHelper::getRemoteBookedSlots() enumerates events on a check calendar, filter out events that originated from Fluent Booking. The extendedProperties already carry a private.fluent_booking_id (or similar) on events the plugin writes — skip any event whose extendedProperties match the running site. Same fix applies to Outlook / Apple / Nextcloud conflict checkers, which share the pattern.
    Happy to share the relevant settings or test on my install if useful.