docs: correct the notmuch malformed-query claim

The previous commit, the spec and the plan all said notmuch exits 0 on a
malformed query while printing something that is not a count, and that
validating the output as an integer therefore catches it. Measured properly,
that is wrong in a way worth recording, because the truth is worse.

notmuch fails two different ways. A rejected query prints nothing and exits 1:
`notmuch count 'tag:unread and ('`. A query Xapian merely misparses returns a
plausible wrong number and exits 0: `notmuch count 'tag:unread and (('` gives
41, and `'tag:unread and tag:'` gives 3. The second is undetectable by any
check on the output, which is why the original claim was not just imprecise
but inverted: the case it described as caught is the case nothing can catch.

The integer validation still earns its place, on the first failure mode, where
empty output would otherwise render as an empty inbox. The real defence
against the second is that QUERY is a fixed string and is never built from
anything, which the comment now says.

The earlier measurement that produced the wrong claim read 40 as mangled
output when it was a successful parse answering a different question.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WWL8JYHu7yhAdtx5pU9PMU

1 files changed, 6 insertions, 4 deletions

diff --git a/mail-overview/waybar-mail.sh b/mail-overview/waybar-mail.sh
index 06f8427..ee07ecb 100755
--- a/mail-overview/waybar-mail.sh
+++ b/mail-overview/waybar-mail.sh
@@ -30,10 +30,12 @@ emit() {
     local n
     n="$(notmuch count "$QUERY" 2>/dev/null)"
 
-    # notmuch exits 0 even for a malformed query, printing something that is
-    # not a count, so the exit status is not the test: the output is. Anything
-    # that is not a plain number is a failure, and a failure must not render
-    # as "no new mail".
+    # The output is the test, not the exit status. notmuch fails two different
+    # ways: a rejected query prints nothing and exits 1, while a query Xapian
+    # merely misparses ('tag:unread and ((') returns a plausible wrong number
+    # and exits 0. Only the first is detectable, and it is the one that matters
+    # here, because empty output would otherwise render as "no new mail". The
+    # second is why QUERY is a fixed string and not built from anything.
     if [[ ! "$n" =~ ^[0-9]+$ ]]; then
         printf '{"text":"!","tooltip":"notmuch count failed","class":"error"}\n'
         return