Two of the three mark-read paths discard the result: a message can be shown and stay unread, silently

[fujibee]

Two of the three places that mark a message read discard the result, so a message can be displayed
and then remain unread with nobody told. Found while measuring #1001; recording it separately
because it is not that issue's defect and it interacts with #677.

The sites

scripts/inbox.sh:89         storage_mark_read_batch … >/dev/null 2>&1 || true
scripts/check-inbox.sh:300  storage_mark_read_batch … >/dev/null 2>&1 || true
scripts/watch.sh:757,760    storage_read_cursor_consume …

The first two swallow both the output and the status. The third is the monitor path and is shaped
differently.

Why it matters now

Measured under an artificial writer holding BEGIN IMMEDIATE: a read-only command's wait was 100%
storage_init's schema batch failing with SQLITE_BUSY and being swallowed (#1001). The fix in
flight removes that wait — but it does not change what happens to the actual mark-read write when a
genuine writer contends. That write can still lose, and || true means:

• the operator sees the message printed;
• the row stays unread;
• the exit status is 0;
• nothing is written anywhere.

The next inbox shows it again. That is benign-looking — a duplicate is not a loss — but it is the
mirror of the failure #677 reports, where a message was consumed without being shown. Here it is
shown without being consumed. Both come from the same place: mark-read and delivery are not tied
to each other's success.

The retry pattern already exists here

scripts/drivers/storage/sqlite.sh:274-282, the send path:

if ! printf '%s\n' "$insert" | agmsg_sqlite -bail "$db" >/dev/null 2>&1; then
  storage_init "$team" >/dev/null
  printf '%s\n' "$insert" | agmsg_sqlite -bail "$db" >/dev/null 2>&1 || return 1
fi

Write, and on failure initialise and write again — and return non-zero if it still fails. The
pattern was built for #114 and applied to the send path only. The read paths kept || true.

What is not established

• Whether this fires in practice. The measurement above forced contention artificially; nobody
  has caught a real mark-read losing to a real writer. The failure is silent, so an absence of
  reports is not evidence of absence — which is itself part of the problem.
• Whether watch.sh's consume has the same hole. It is a different call with different failure
  handling and was not examined.

What would settle it

Instrument the two call sites to report a failed mark-read (to stderr, or as an event), then look at
whether it ever appears. That is small, and it converts "we would not know" into "we would". Applying
the #114 retry is the fix if it does fire; adding a retry to something never observed to fail would
be the wrong order.

Related: #677 (the same seam, opposite direction), #1001 (how this was found), #114 (where the
pattern comes from).

[fujibee]

Correcting this issue — I grouped three call sites by a surface detail and missed that one of them
already has the contract the other two lack.

I listed inbox.sh:89, check-inbox.sh:300 and watch.sh:757,760 as three instances of the same
swallow, on the grounds that all three end in >/dev/null 2>&1 || true. That is true of the
statement, and false of the path. Looking at what precedes each one:

watch.sh:746
  if ! printf '%s | %s | %s → %s | %s\n' "$ts" "$team" "$from" "$to" "$body"; then
    cleanup
    exit 0
  fi
  DELIVERED_IDS+=("$id")        <- only ids whose write to the stream succeeded
  …
  storage_read_cursor_consume … "${DELIVERED_IDS[@]}"

watch.sh already ties consumption to delivery. If the write to the stream fails, it stops
rather than continuing, and only ids that were actually written reach the consume call. The || true
there covers the consume itself, not the question of whether the message was delivered. That is the
contract the other two are missing, and it is already in the tree.

The ordering across the three, which is what actually separates them:

inbox.sh        read -> print          -> mark      print first
watch.sh        read -> print or stop  -> consume   print first, and only what printed
check-inbox.sh  read -> mark (:300)    -> print     MARK FIRST

Two of the three are already correct. One is not, and it is check-inbox.sh — the same site
#677 is about, where a message can be consumed and then fail to be shown.

So the shape of this issue changes:

• Not "two of three paths discard the result". inbox.sh discards the status of a mark that
  happens after a successful print, which is a much smaller thing: the message was shown, and it may
  be shown again. Worth a diagnostic line, which is being added.
• The real asymmetry is check-inbox.sh marking before printing, with no link between the two.
  That belongs to Possible race between manual inbox check and turn-mode Stop hook marks a message as read without displaying it #677 and its Windows mechanism (a -l login shell prepending profile output to the
  hook's JSON, so the JSON is rejected after the rows were already marked read).

What survives unchanged: the || true on inbox.sh:89 means a failed mark is silent, so a message
can be shown and stay unread with nobody told. That is still worth the diagnostic, and it is still
true that the #114 retry pattern (sqlite.sh:274-282) was applied to the send path only.

Why I got it wrong: I grepped for the swallow and treated matching syntax as matching semantics,
without reading what came before each call. The distinguishing fact was ten lines up. Credit for
catching it goes to the seat that enumerated both sides — writers and readers — rather than only
the side I had asked about.

[fujibee]

Answering the second "not established" item — watch.sh's consume was examined (read only, no change):

It is not shaped differently in the way that matters. Both call sites swallow the result exactly like the inbox did:

scripts/watch.sh:757-761
storage_read_cursor_consume "$pair_team" "$pair_agent" "$FINAL_CURSOR" \
  "${DELIVERED_IDS[@]}" >/dev/null 2>&1 || true

storage_read_cursor_consume does report failure — its BEGIN IMMEDIATE batch returns runtime_error/13 when it loses to a writer (scripts/drivers/storage/sqlite.sh:313) — so the status reaches the caller and is then discarded.

The consequence differs from the inbox case in one way: on failure the cursor does not advance and the delivered ids are not recorded, so the same messages are delivered again on the next poll cycle — duplicates in the monitor stream rather than a lingering unread row. Same seam, same swallow, different visible symptom.

Instrumentation for the first two sites is on obs/1011-mark-read-report (inbox.sh done; the check-inbox site is coordinated separately because of #677 overlap).

[fujibee]

Second correction to this issue, and this one is about a claim I made that a reviewer disproved by
looking at a driver I did not.

I wrote that a failed mark-read leaves the message "unread, and it will be shown again". That is true
of the SQLite driver and not true of the facade:

SQLite   storage_read_cursor_consume is one transaction
         -> on failure every id stays unread, and the message is shown again.   my claim holds

JSONL    _jsonl_mark appends message_read events FIRST; if the subsequent tip re-read or
         cursor-file write then fails, the control op returns non-zero
         -> some or all ids are ALREADY READ and will not be shown again.       my claim is false

So a diagnostic that promises re-display is wrong on one of the two shipped drivers — and the promise
is the part an operator acts on. Told "it will appear again", they wait for it; on a JSONL store it
does not come.

What I did wrong: I read one storage driver and wrote the sentence as if it described the facade.
storage_mark_read_batch is a facade call with more than one implementation behind it, and the two
differ in exactly the property I was asserting.

The corrected shape of the diagnostic (being applied to inbox.sh): report the observation, not
the consequence — that the mark-read call returned non-zero for N messages — without claiming what
happens next. Which ids survived as unread is driver-dependent, and the caller does not know which
driver it is talking to. This is the same discipline applied in #1008, where kill -0 returning false
was narrowed to "could not confirm it running" rather than "it exited".

Everything else in this issue's previous correction stands: watch.sh already ties consumption to
delivery, check-inbox.sh marks before printing and belongs to #677, and the #114 retry pattern in
sqlite.sh:274-282 was applied to the send path only.