[Bug]: In-app notification badge never clears after marking notifications as read

[chrisdebian]

Summary

The notification count badge on the Contributions screen never clears, even after tapping notifications to mark them as read. The badge count persists across sessions and app restarts.

Steps to reproduce

1. Open the app with at least one unread notification (badge visible on the bell icon)
2. Tap the bell to open the notifications list
3. Tap one or more notifications (each opens its linked URL)
4. Return to the Contributions screen
5. Observe the badge count — it is unchanged

Expected behaviour

After tapping a notification (which calls `markAsRead`), the badge count should decrease. Once all notifications are read, the badge should disappear.

Actual behaviour

The badge count does not decrease. Notifications appear permanently unread. The "Notification marked as read" snackbar (shown on success in `NotificationActivity`) never appears.

Root cause (from code inspection)

In `NotificationActivity.removeNotification()`:

1. `markNotificationAsRead()` in `NotificationClient` calls `csrfTokenClient.getTokenBlocking()` before sending the API request. If token acquisition fails for any reason (expired session, network issue), it catches the exception and returns `Observable.just(false)` — with no user-facing error.

2. The `false` result causes the notification to remain in the local list and on the server. When the user returns to `ContributionsFragment`, `setNotificationCount()` re-fetches from the server and shows the same count.

3. The disposable from the `subscribe()` call in `removeNotification()` is not added to a `CompositeDisposable` (suppressed with `@SuppressLint("CheckResult")`), risking a lost result if the Activity is paused mid-call.

Fix sketch

• Add user-visible error feedback in the `else` branch of `removeNotification()` (currently silently ignores failure)
• Track the disposable in a `CompositeDisposable` and dispose on `onDestroy`
• Consider whether CSRF token failure should trigger a re-login prompt

Device name

Pixel 6

Android version

Android 16

Commons app version

6.6.0-beta (debug build)

[chrisdebian]

Device-tested root cause confirmed (Pixel 6 / Android 16, beta debug build):

Tapping a notification:

1. Removes it from the local list (API returned success: true) ✓
2. On return to the Contributions screen, setNotificationCount() re-fetches — the notification reappears as unread

Diagnosis: echomarkread in NotificationInterface is called via the Commons API endpoint (MW_API_PREFIX) with no wikis parameter. But getAllNotifications fetches from wikidatawiki|commonswiki|enwiki. Notifications originating on enwiki or wikidatawiki (thank-yous, featured image nominations, etc.) are sent to the wrong endpoint — the Commons API returns success but the mark-read is never applied on the originating wiki.

Fix options:

1. Add a wikis parameter to the echomarkread call — MediaWiki supports this since 1.32 and the Wikimedia cluster is well past that.
2. Store the source wiki on the Notification model and dispatch each mark-read to the correct API host.