fix(mail-overview): don't re-notify the prior batch, flatten newlines

The lastmod range is inclusive at both ends and the stored revision
was reused as the next start, so the batch just notified matched
again. Start one revision later.

A subject can contain a newline, which broke the bullet rows and the
+N more count; flatten CR/LF to a space before escaping.

Also reconciles the state-write comment and spec with the actual
skip-and-advance failure behavior, and corrects two doc wordings.

1 files changed, 10 insertions, 5 deletions

diff --git a/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md b/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md
index 93dc13c..1423fe9 100644
--- a/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md
+++ b/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md
@@ -59,12 +59,14 @@ revision is field 3. Verified on notmuch 0.39.
 Per tick, if the revision has not advanced, there is nothing to do. Otherwise,
 per account:
 
-    notmuch count "tag:unread and tag:inbox and tag:account-<key> and lastmod:<prev>..<cur>"
+    notmuch count "tag:unread and tag:inbox and tag:account-<key> and lastmod:<prev+1>..<cur>"
     notmuch search --format=json --limit=3 --sort=newest-first "<same query>"
 
 Two calls, the same count-plus-preview pair `Accounts.qml` already makes, and
 only for accounts whose query is non-empty. The count gives the true N for
-"+N more"; the search gives the rows.
+"+N more"; the search gives the rows. The lower bound is exclusive (`prev+1`)
+so the revision just written, which is inclusive at the top end, is not
+re-matched on the next tick.
 
 `search --format=json` returns `authors` and `subject` directly, which is all
 the body needs.
@@ -95,9 +97,12 @@ was down is never notified. This is the right trade: the waybar count is still
 correct and the drawer still shows the mail, so nothing is lost except a
 popup that would have been stale anyway.
 
-The new revision is written **after** every account has been processed, so a
-failure mid-loop leaves `prev` unchanged and the next tick retries rather than
-dropping a batch silently.
+The new revision is written **after** every account has been processed. A
+single account whose count does not validate is skipped for that tick, and the
+revision still advances: holding it back would make every later tick re-notify
+the successful accounts' whole range. Only a failure to write the state file
+itself is non-fatal and leaves the old revision, so the next tick re-notifies
+rather than dropping mail.
 
 ## Accounts