Bound initial notification reads

[raymondjacobson]

Summary

• Bound unread notification polling to the newest 25k single-recipient and 25k multi-recipient candidates before grouping.
• Bound first-page and timestamp notification reads to newest candidate groups, then cap expensive validation/JSON aggregation to the newest 100 actions per selected group.
• Reuse the read-only transaction with scoped SET LOCAL enable_seqscan = off for candidate-limited notification reads, including unread polling.

Why

• Today after PR Optimize notification timestamp pagination #988, the remaining failures shifted to first-page limit=20 and unread limit=0, not just timestamp pagination.
• Since midnight Pacific on 2026-07-07, Cloud Logging showed 49 notifications unread query timed out and 13 notifications query timed out messages.
• The hot first page for eJ57D includes giant groups: roughly 11.7k save:4281:type:playlist rows and 12.3k follow:51 rows inside the newest candidate groups. Candidate rows alone were still too many for the full validation/aggregation stack.

Live validation

• Bounded unread query for eJ57D returned count 20 in ~0.6s.
• First-page candidate rows without action capping still timed out under the 8s statement timeout when the full filter stack was included.
• First-page full filter stack with newest 100 actions per selected group returned a full 20-group page in ~0.42s.

Product impact

• Very large notification groups now return the newest 100 actions for that group in candidate-limited reads instead of trying to return thousands of action rows.
• The endpoint still returns the same response shape and group ordering, but giant grouped notifications may include fewer action objects.

Test plan

• go test ./api -run ^'$'\n- Attempted go test ./api -run TestV1Notifications; blocked locally because the test DB at localhost:21300 is not running.