/api/notifications/all fails for user with large notification volume (e.g., dataverseAdmin)

Bug Report: /api/notifications/all fails for user with large notification volume

Environment

• Branch: develop (latest as of July 2025)
• User: dataverseAdmin (has thousands of notifications)
• Tested during: PR testing for #11664
• API Call:

  curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all"
  
  

Bug Description
The /api/notifications/all endpoint fails when invoked by a user who has a very large volume of notifications. This issue was discovered while testing PR #11664, but it exists in the develop branch independently of that PR.

Steps to Reproduce
Log in as a superuser or admin account with thousands of notifications (e.g., dataverseAdmin)

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all"
Observe that the API call fails (e.g., no response or internal server error)

Expected Behavior
The API call should return the user's notifications, or at least respond with a subset (paginated or filtered), without crashing or timing out.

Actual Behavior
The request fails entirely

**

11664 server.log

**
Relevant stack trace is available in the server.log from internal testing.

Notes
This is not a regression introduced by PR #11664

Suggested Fix
Add pagination support to /api/notifications/all
Add filtering options (e.g., ?type=..., ?since=...)
Enforce maximum limits and document default behavior for large volumes

Start with the /api/notifications/all entry point and reproduce the failure using the curl command for an account with thousands of notifications. Review the linked server.log for the relevant stack trace and determine the response limits or pagination behavior needed. Done means the endpoint returns a bounded notification result without crashing or timing out.