Facility booking-mode redesign, multi-plan subscriptions, and Classes

Implements the facility-classes-booking-dashboard plan (backend):

- Facility.BookingMode (single Scheduled/AdHoc choice) replaced with
  independent SupportsClasses/SupportsBooking flags, so one facility
  can run a class and accept walk-in bookings; a running class now
  blocks walk-in booking for its window on both create and reschedule.
- CustomerPlan.GrantsGymAccess + CustomerPlanClass join table let a
  customer hold one gym-access plan plus any number of class-only
  plans. Replaced the old single-subscription resolution
  (GetActiveSubscriptionByCustomerId/HasAnyActiveSubscriptionAsync)
  with gym-access-aware and class-aware resolvers across booking
  creation/cancellation, plan assignment, and customer self-service.
  Fixed ChangeMembershipPlan/renewal plan-changes, which resolved "the
  subscription to replace" by most-recent-created and would have
  deactivated a member's class subscription instead of their gym one.
- New FacilityClass model: recurring class definitions (Daily/Weekly/
  Monthly/Custom) with lazy occurrence generation (8-week horizon,
  race-safe via a unique index) and proper unlimited-capacity handling.
  "Mark not held" replaces the old bare-cancel: cascades to cancel and
  refund every confirmed booking on the occurrence through the same
  core CancelBooking uses, and frees the slot for walk-in booking.
  Scheduling conflicts (a walk-in booking now overlapping a class) are
  surfaced for staff to resolve via the existing Reschedule flow.
- Renamed the pre-existing "AdHoc" booking-mode terminology to
  "WalkIn" throughout (routes, methods, DTOs, the stored BookingMode
  value) for a clearer, simpler name.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Repos/ClientRepository.cs

@@ -354,12 +354,22 @@ namespace Fitness_core_BE.Repos
         // Unlike CustomerSubscription.FKCustomerId (which only ever points at the primary
         // member), this resolves the caller's own SubscriptionMember row whether they're
         // the primary or a secondary member of a group subscription.
+        // Both callers (ClientService.ChangeCustomerMembershipPlan,
+        // SubscriptionRenewalApprovalService.ChangePlanAsync) reject a Group-scope new plan and
+        // are conceptually "swap the member's individual gym plan" -- so this must resolve to
+        // their GYM-ACCESS subscription specifically, not just whichever active subscription
+        // happens to be most recently created. Without this filter, a member holding both a gym
+        // plan and a class-only plan would have their class subscription silently deactivated
+        // and replaced instead of their gym one, once a class subscription could outrank it by
+        // CreatedAt.
         public async Task<SubscriptionMember?> GetActiveMembershipForCustomerAsync(Guid customerId, CancellationToken ct = default)
         {
             return await _dbContext.SubscriptionMembers
                 .Include(m => m.Subscription)
                     .ThenInclude(s => s.CustomerPlan)
                 .Where(m => m.FKCustomerId == customerId && m.IsActive && m.Subscription.IsActive)
+                .Where(m => !_dbContext.CustomerPlanClasses.Any(c => c.FKCustomerPlanId == m.Subscription.FKCustomerPlanId)
+                    || m.Subscription.CustomerPlan.GrantsGymAccess)
                 .OrderByDescending(m => m.Subscription.CreatedAt)
                 .FirstOrDefaultAsync(ct);
         }