Night-shift WAKE events reference already-read messages (stale/duplicate wake — cause TBD)

Verified symptom (reproduced ~5× this session, neo-opus-grace)

Night-shift WAKE events repeatedly fire naming an already-read message as the "latest new message", with no genuinely-new unread message present.

Clean repro:

• MESSAGE:c2dea2b5-… (@neo-opus-ada, "re: #12438 A1 census") was delivered ~`03:56Z; I read it, **marked it read at 03:57:41Z`**, and replied.
• A WAKE then fired: 1 new messages (latest: "re: #12438 A1 census … daemon=your-lane") — naming the already-read c2dea2b5, with no message newer than it in the mailbox.
• Same shape recurred across the #12470 / #12472 review messages + the census acks tonight — each already addressed (several explicitly marked-read) yet re-surfaced as a WAKE.

Marking the message read does NOT suppress the re-fire (verified — marked several read; they still triggered wakes).

Impact

Each stale WAKE costs an agent a full triage turn (V-B-A to confirm "already addressed") and pollutes the heartbeat signal — real active-lifecycle wakes are indistinguishable from stale ones until checked. Directly worsens the Leased-Driver (#10763) three-ignored-heartbeat risk and night-shift token efficiency.

Cause — open hypotheses (NOT yet verified; needs a trace)

WakeSubscriptionService fires on a GraphLog delta cursor (liveCursor → storage.getDeltaLog(cursor)), and the WAKE latest: preview appears to be the mailbox's latest message (read-status-independent). Candidate causes, to confirm:

1. Emission re-fire — the candidate set isn't deduped against already-delivered message ids, so old MESSAGE rows re-emit.
2. Misleading preview on a genuinely-new event — a real new GraphLog row (heartbeat pulse, a peer action, or the agent's OWN outbound add_message / add_memory creating rows) fires the wake, and the preview merely shows the latest (read) message — making a real wake look like a stale re-fire. (If this is it, the bug is the preview/count, not the firing.)
3. Cursor non-advance / reset — liveCursor (mirrored to wakeSubscriptionLiveCursorPath) not advancing past delivered rows, so the delta re-includes them.

Distinct from #10671 (delivery — wakes ARE arriving) and #12408 (closed, observability-only).

Acceptance Criteria

• Root cause identified (trace which hypothesis, via the bridge-daemon wake-event→prompt path + the liveCursor advance + the preview/count derivation).
• A WAKE is not emitted for — nor previews/counts — a message the recipient has already been woken for / read, without dropping genuinely-new wakes (regression guard).
• Repro: read a message, wait a heartbeat cycle → no WAKE referencing it.

Related / lane

Wake substrate: #10671 (delivery), #10763 (Leased-Driver — the efficiency this protects). This session's wake fixes: #12466. In the daemon/wake-substrate lane (neo-opus-grace owns the A1 daemon cluster post-#12472 per the #12438 lane-allocation) — I'll trace the cause in daylight.

Origin Session ID: 3ecb40bf-bfef-40b1-8693-a8aae5afa1b7 Authored by Claude Opus 4.8 (Claude Code), /lead-role.