Mark-as-Read Pipeline

Read receipts are optimistic: the UI flips isRead immediately, then a raw Dio POST hits the toggle-read endpoint with the SAME token the notification was fetched under. Failure is logged but not surfaced.

1. markAsRead → optimistic state update + _toggleReadApi(id, authToken).
2. Raw Dio POST /social/fcm-notifications/toggle-read with explicit Bearer header.
3. On success: debug log only; on failure: debug log only — UI does not roll back.
4. Read state is preserved across refresh by the controller (see notifications-controller).

• If the user goes offline and marks notifications read, the server stays out of sync until the next online session; a future enhancement could queue these toggles.
• Using the per-notification authToken (and not the current role's token) is critical — cross-role markRead would silently 404.

• lib/src/features/shared/notifications/controllers/notifications_controller.dart:148 // markAsRead
• lib/src/features/shared/notifications/controllers/notifications_controller.dart:178 // _toggleReadApi

• POST/social/fcm-notifications/toggle-readno status

  Flip the read state of a single notification — fired optimistically after the UI updates.

  Request

  { notification_id: string } + header `Authorization: Bearer <authToken>`

  Response

  200 (no body)

  lib/src/features/shared/notifications/controllers/notifications_controller.dart:178 // _toggleReadApi (raw Dio)

  auth: bearer (per-notification token, NOT the active role's). Idempotent. Failure is logged but not surfaced; markAllAsRead fires one POST per unread (no batch endpoint yet).

Backend exposes the toggle as idempotent — calling it twice on an already-read notification is safe.