fix(unread): stop stuck/resurrecting read indicators

handleReceipt recomputed unread from getUnreadNotificationCount, which is
server-computed and stale on the synchronous synthetic receipt echo (the SDK
only zeroes it immediately when the last event is our own message). Reading
someone else's message therefore PUT the stale non-zero count back -> dot stuck
or resurrected on the ack-sync ordering race. Restore upstream cinny's
optimistic DELETE on our own receipt; the UnreadNotifications listener re-asserts
the accurate badge on the server ack.

Also collapse a {total:0,highlight:0} PUT to a DELETE in the reducer (a present
map entry lights the dot via hasUnread=!!unread, so phantom {0,0} PUTs from the
UnreadNotifications listener left stuck dots).

Mark-as-Unread (MSC2867): clear the flag directly in markAsRead (opening an
already-read room sends no receipt, so the receipt-driven auto-clear never
fired), and gate the receipt auto-clear to main/unthreaded receipts so reading
one thread no longer wipes the whole-room flag.

Tests: 700/700 pass; typecheck + prod build clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

LOTUS_TODO.md

@@ -62,9 +62,11 @@ Built and gate-green; verify per [LOTUS_TESTING.md](./LOTUS_TESTING.md), then gr
 
 ## 🔴 Open — Actionable
 
-### 🐛 Unread/read-receipt flakiness (reported 2026-07, live) — INVESTIGATING
+### ✅ Unread/read-receipt flakiness (reported 2026-07) — FIXED (pending prod QA)
 
-Room unread indicators are **inconsistent**: reading a message sometimes clears the dot, sometimes leaves it stuck, and **sometimes the unread comes back after it was read** (resurrects). This is the same subsystem as the Wave-1 fixes (T1 `markThreadAsRead` root receipt, N1 favicon double-count, N2 dedupe cache, N4 blanket-DELETE) plus the newly-added **Mark as Unread (MSC2867)** `markedUnreadAtom` — a prime suspect for interference. Look closely at: `state/room/roomToUnread.ts` (handleReceipt recompute vs DELETE, RESET triggers), `utils/notifications.ts markAsRead`, `features/room/thread/threadReceipt.ts`, `state/room/markedUnread.ts` (its Receipt listener + the `unread || markedUnread` dot), and `threadIdForReceipt`/unthreaded-receipt handling. Repro: read a message → dot lingers or returns. Planning session.
+Room unread dots were inconsistent: reading a message sometimes cleared the dot, sometimes left it stuck, sometimes it resurrected. Root cause (confirmed by tracing + diffing upstream cinny `dev`): **our own "N4" change.** `handleReceipt` recomputed via `getUnreadInfo`, which reads `room.getUnreadNotificationCount()` — server-computed and **stale on the synchronous synthetic receipt echo** (SDK only zeroes it immediately when the last event is your own message) → it PUT the stale non-zero count back → stuck/resurrecting. Compounded by `hasUnread = !!unread` lighting the dot on any present map entry, incl. phantom `{0,0}` PUTs from our `UnreadNotifications` listener. Plus a Mark-as-Unread (MSC2867) flag that never cleared on opening an already-read room (no receipt → no auto-clear).
+
+**Fix:** `roomToUnread.ts` — `handleReceipt` reverts to upstream's optimistic `DELETE` on own receipt; reducer collapses `{0,0}` PUT → DELETE. `notifications.ts markAsRead` clears the marked-unread flag directly. `markedUnread.ts onReceipt` gated to main/unthreaded receipts (`myMainReceiptPresent`). Unit tests added; 700/700 pass, typecheck + build clean. Deploy + manual QA (read → dot clears & stays; thread read; mark-unread → open → clears; reconnect no resurrect).
 
 ### 🧨 Encryption / E2EE — ⚠️ EXTREME COMPLEXITY · 🧠 PLANNING SESSION REQUIRED