perf(core): add composite index on notifications to fix slow unread count queries

Fixes #3952. On forums with large notification tables, the unread/new
notification count queries (serialized on every page load via
CurrentUserSerializer) were performing a full table scan. MySQL abandons
the single-column user_id index when one user owns a significant fraction
of the table, which is common on active forums.

The fix adds a composite index (user_id, is_deleted, read_at, type) so
MySQL can use a range scan on (user_id, is_deleted=0, read_at IS NULL)
and satisfy the entire count query from the index without scanning the
table. In the realistic production case (a user with many read
notifications and a small number unread), this reduces the rows examined
from ~1M to the exact unread count.

Benchmarked against a 1M-row table with 200k notifications for one user
(5k users total, two notification subject types to exercise both
visibility scoping branches):

  Realistic case (500 unread / 200k total for user):
    Before: 86ms  — full table scan, ~1M rows examined
    After:   3ms  — index range scan, 500 rows examined (96% faster)

  Worst case (200k unread / 200k total for user):
    Before: 106ms — full table scan, ~1M rows examined
    After:  124ms — index range scan, ~200k rows examined

The worst case (user has never read any notification) shows a slight
regression because the index scan still visits 200k rows. This scenario
is not realistic in production, and on a cold disk-backed database the
index would still outperform the full scan.

No code changes — visibility scoping is fully retained and there are no
breaking changes for extensions.

Author: imorland

framework/core/migrations/2026_03_25_000000_add_notifications_composite_index.php

@@ -0,0 +1,39 @@
+<?php
+
+/*
+ * This file is part of Flarum.
+ *
+ * For detailed copyright and license information, please view the
+ * LICENSE file that was distributed with this source code.
+ */
+
+use Illuminate\Database\Schema\Blueprint;
+use Illuminate\Database\Schema\Builder;
+
+return [
+    'up' => function (Builder $schema) {
+        $schema->table('notifications', function (Blueprint $table) {
+            // Composite index to support the unread/new notification count queries
+            // issued on every page load. Without this, MySQL abandons the single-
+            // column user_id index when one user owns a large fraction of the table
+            // (common in active communities) and falls back to a full table scan.
+            //
+            // Column order rationale:
+            //   1. user_id   — equality prefix, mandatory filter on all count queries
+            //   2. is_deleted — equality (always 0 for visible notifications)
+            //   3. read_at   — IS NULL filter for unread; narrows to a small fraction
+            //   4. type      — IN (...) filter; included so the index covers the query
+            //
+            // With this index, the count query can be satisfied with an index range
+            // scan on (user_id, is_deleted=0, read_at IS NULL) without touching the
+            // table rows, regardless of how many notifications a user has in total.
+            $table->index(['user_id', 'is_deleted', 'read_at', 'type'], 'notifications_user_unread_type_index');
+        });
+    },
+
+    'down' => function (Builder $schema) {
+        $schema->table('notifications', function (Blueprint $table) {
+            $table->dropIndex('notifications_user_unread_type_index');
+        });
+    }
+];