perf: fix notifications duplicate query and add composite index (#12110)

Database CPU utilization was spiking due to expensive notification COUNT
queries. Analysis revealed two critical issues:

1. Missing database index: Notification count queries were performing
table scans without proper indexing
2. Duplicate WHERE clauses: SQL queries contained redundant read_at IS
NULL conditions, causing unnecessary query complexity

 ### Root Cause Analysis

  The expensive queries were:
```
  -- 41.61 calls/sec with duplicate condition
  SELECT COUNT(*) FROM "notifications"
  WHERE "notifications"."user_id" = $1
    AND "notifications"."account_id" = $2
    AND "notifications"."snoozed_until" IS NULL
    AND "notifications"."read_at" IS NULL
    AND "notifications"."read_at" IS NULL  -- Duplicate!
```
This was caused by a logic error in NotificationFinder#unread_count
introduced in commit cd06b2b33 (PR #8907). The method assumed
@notifications contained all notifications, but @notifications was
already filtered to unread notifications in most cases.

###  The Default Query Flow:

1. Frontend calls: NotificationsAPI.getUnreadCount() →
/notifications/unread_count
  2. No parameters sent, so params = {}
  3. NotificationFinder setup:
    - find_all_notifications: WHERE user_id = ? AND account_id = ?
    - filter_snoozed_notifications: WHERE snoozed_until IS NULL
- filter_read_notifications: WHERE read_at IS NULL (because
type_included?('read') is false)
  4. unread_count called: Adds another WHERE read_at IS NULL
----
### Solution

  1. Added Missing Database Index
  - Index: (user_id, account_id, snoozed_until, read_at)
  2. Fixed Duplicate WHERE Clause Logic

spec/finders/notification_finder_spec.rb

@@ -66,14 +66,31 @@ RSpec.describe NotificationFinder do
         expect(subject.unread_count).to eq(3)
         expect(subject.count).to eq(3)
       end
+
+      it 'avoids duplicate filtering in unread_count method' do
+        # Test the logical fix: when no 'read' filter is included,
+        # @notifications is already filtered to unread, so unread_count
+        # should just count without adding another read_at filter
+
+        allow(subject.instance_variable_get(:@notifications)).to receive(:where).and_call_original
+        allow(subject.instance_variable_get(:@notifications)).to receive(:count).and_call_original
+
+        result = subject.unread_count
+
+        # Should return correct count without additional where clause
+        expect(result).to eq(3)
+
+        # The fix ensures that when params[:includes] doesn't contain 'read',
+        # unread_count uses @notifications.count instead of @notifications.where(read_at: nil).count
+      end
     end
 
     context 'with filters applied' do
       let(:params) { { includes: %w[read snoozed] } }
 
       it 'adjusts counts based on included statuses' do
-        expect(subject.unread_count).to eq(4)
-        expect(subject.count).to eq(6)
+        expect(subject.unread_count).to eq(4) # 3 unread + 1 snoozed (which is unread)
+        expect(subject.count).to eq(6) # all notifications including read and snoozed
       end
     end
   end