Problem

api_notifications_get was calling array_slice( $notifications, 0, $limit ) on the full accumulated notifications array. This broke pagination in two ways:

1. Any handler injecting notifications at a filter priority lower than 10 would have its items truncated before finalize_notifications() could apply proper max_id/min_id pagination.
2. The sort+slice happened before all sources had contributed, so the final merged set was already incomplete when finalize_notifications() ran.

Solution

EMA now passes three additional arguments to the mastodon_api_notifications_get filter:

• $limit — the clamped page size
• $before_date — derived from max_id, or null
• $after_date — derived from min_id/since_id, or null

This is backward compatible — existing handlers registered with add_filter( ..., 10, 2 ) receive only the first two arguments and are unaffected.

When $before_date or $after_date is provided, this handler switches to date-constrained queries (date_query on get_comments(), date_query on Followers::get_many()) so the fetch is bounded to the relevant pagination window without truncating the shared pool. When no date window is set (first page), it falls back to $limit as before.

Test plan

• Verify existing EMA notification tests pass
• Manually verify reblog/like/follow notifications appear correctly on first page
• Manually verify paginating through notifications with max_id returns the correct next page

Changelog entry

• Automatically create a changelog entry from the details below.