Reduce notification timeout long tail (#990)

## Summary
- use a smaller candidate window for timestamp pagination so old
notification scrollback does not read tens of thousands of historical
rows before grouping
- give unread polling its own shorter timeout and return a conservative
capped unread response instead of surfacing a 504 when the
multi-recipient array path is cold

## Production evidence
- slow dEKBy cursor with the existing 25k candidate window read ~23.4k
rows and built ~2.9k groups before trimming
- the same cursor with a 2k candidate window still produced >600 groups
and planned/executed in ~51ms warm during read-only production probing
- unread timeout case for user 843 was dominated by the multi-recipient
GIN path scanning ~42k historical rows to find 7 current unread rows, so
this PR fails closed for the poll while we plan the
recipient-normalized/index follow-up

## Validation
- go test ./api -run '^$'
- git diff --check

## Notes
- go test ./api -run TestV1Notifications is blocked locally because
Postgres on localhost:21300 refused connections

Author: raymondjacobson

api/v1_notifications.go

@@ -30,6 +30,10 @@ const (
 	// holding hot-standby snapshots and making the replica fall behind.
 	notificationReadTimeout = 8 * time.Second
 
+	// Unread polling runs frequently in clients. If the multi-recipient array
+	// path is cold, fall back quickly instead of surfacing a 504.
+	notificationUnreadPollTimeout = 3 * time.Second
+
 	// Historically `limit=0` fell back to the default limit of 20, so unread
 	// polling counted at most the first page of notification groups.
 	notificationUnreadPollLimit = 20
@@ -39,6 +43,11 @@ const (
 	// LIMIT.
 	notificationReadCandidateLimit = 25000
 
+	// Old timestamp pagination can still have years of history behind the
+	// cursor. A smaller window is enough to find many candidate groups while
+	// avoiding cold reads over tens of thousands of historical rows.
+	notificationTimestampPaginationCandidateLimit = 2000
+
 	// Keep the expensive validation/JSON aggregation work bounded after the
 	// newest notification groups have been selected.
 	notificationGroupCandidateLimit  = 200
@@ -143,7 +152,7 @@ FROM (
 	LIMIT @limit
 ) unread_notifications;
 `
-	ctx, cancel := context.WithTimeout(c.Context(), notificationReadTimeout)
+	ctx, cancel := context.WithTimeout(c.Context(), notificationUnreadPollTimeout)
 	defer cancel()
 
 	var unreadCount int
@@ -158,7 +167,17 @@ FROM (
 	})
 	if err != nil {
 		if errors.Is(err, context.DeadlineExceeded) {
-			return fiber.NewError(fiber.StatusGatewayTimeout, "notifications unread query timed out")
+			return c.JSON(fiber.Map{
+				"data": fiber.Map{
+					"notifications": []notificationRow{},
+					"unread_count":  notificationUnreadPollLimit,
+				},
+				"related": fiber.Map{
+					"users":     []any{},
+					"tracks":    []any{},
+					"playlists": []any{},
+				},
+			})
 		}
 		return err
 	}
@@ -578,6 +597,10 @@ limit @limit::int
 ;
 `
 	userId := app.getUserId(c)
+	candidateLimit := notificationReadCandidateLimit
+	if params.Timestamp > 0 {
+		candidateLimit = notificationTimestampPaginationCandidateLimit
+	}
 
 	ctx, cancel := context.WithTimeout(c.Context(), notificationReadTimeout)
 	defer cancel()
@@ -592,7 +615,7 @@ limit @limit::int
 	}
 
 	if usesCandidateLimit {
-		args["candidate_limit"] = notificationReadCandidateLimit
+		args["candidate_limit"] = candidateLimit
 		args["group_candidate_limit"] = notificationGroupCandidateLimit
 		args["actions_per_group_limit"] = notificationActionsPerGroupLimit
 	}