[BE-58] Notification preferences: per-type and per-channel controls

[yusuftomilola]

Overview

All notifications are currently sent unconditionally — members receive emails and in-app alerts regardless of their preferences. Notification fatigue drives members to ignore all alerts. Per-type, per-channel preference controls are a standard expectation on any platform.

Context

• CreateNotificationProvider: backend/src/notifications/providers/create-notification.provider.ts
• EmailModule: backend/src/email/ — all email sends need preference checks
• NotificationType enum: backend/src/notifications/enums/notification-type.enum.ts

Tasks

• Create NotificationPreference entity: id, userId (unique FK), bookingUpdates (bool, default true), paymentAlerts (bool, default true), communityMessages (bool, default true), announcements (bool, default true), eventReminders (bool, default true), waitlistAlerts (bool, default true), emailEnabled (bool, default true), inAppEnabled (bool, default true), smsEnabled (bool, default false), pushEnabled (bool, default true), updatedAt
• GET /notifications/preferences — returns current user's preferences; auto-creates a default record if none exists yet
• PATCH /notifications/preferences — partial update (e.g. { "announcements": false, "emailEnabled": false })
• Update CreateNotificationProvider: before creating an in-app notification, fetch the user's NotificationPreference and skip if inAppEnabled = false or the relevant category toggle is off
• Add a preference check helper notificationPreferencesService.shouldSend(userId, type, channel) for use in EmailModule callers

Files to Modify / Create

• New: backend/src/notifications/entities/notification-preference.entity.ts
• New: backend/src/notifications/providers/notification-preferences.provider.ts
• backend/src/notifications/notifications.controller.ts
• backend/src/notifications/providers/create-notification.provider.ts