Some notes as preparation for the pull request:
The approach used in legacy code and the Paging3/RemoteMediator approach have some key differences.
All data from the server is loaded into the database, page by page.
The data from the database is then loaded completely into memory and filtered, sorted.
At least this is my understanding of what the legacy code does.

Update:
Note to above post: Room-database query was executed with in-memory database. Hence, the data is not valid.

I created an initial version of a refactored view model/repository which works entirely with a Room-database and does not do any Kotlin-based in-memory manipulation to sort/filter the data.
I ran the tests on a P101-EEA with 3.0GB RAM and Android 10
I created a synthetic dataset of 1000 notifications which filters down to 56 notifications using various exclusions currently implemented.
Each experiment did 100 repetitions (using the same filtering parameters). I repeated each experiment three times.
All data in milliseconds

Insights from my ongoing analysis.

Issued PR

The problem with the code in LinkHandler is that if the url embedded in the messagePayload transferred to onMessage contains an encoded space character (%20). UriUtil.decodeURL will decode it and replace it with a real space character. This is then passed to onUrlClick where it is assigned to the local variable href. This local variable is then used to create an Uri which is assigned to the local variable uri. In this step, the space character is not encoded again. When passing uri to external browsers using onExternalLinkClicked, it depends on the functionality of the browser how the raw space character is interpreted. Apparently, DuckDuckGo (and potentially further browsers) process only the first part of the uri - ignoring the second part after the space character.

PR has been issued.

Furthermore, I would like to reference from another ticket:
According to the Q&A section in this page edit stats are updated once a day.

I analyzed UserContribListViewModel: The edit count and the actual contributions are retrieved using two different API endpoints.
loadStats queries using userInfoWithMessages and posts UserContribStats using editCount from UserInfo.
There is no logic in the app which modifies the editCount.
The actual contributions come from the method load in the inner class UserContribPagingSource.
Using the number of actual contributions would be incorrect since paging and filtering is applied.
IMHO, this (temporary?) incorrect display of edit count is probably a performance limitation in the backend which cannot be overcome by adaptation of the app's logic.