findings of the reviews of audit stage 1

Technical review (Opus) and security review (Fable) of 9efc9c7..a59e3d4;
reports in the session's scratchpad. Fixed:

- B1 (verified bug): store.UpdateStatus read before writing in its
  transaction; a commit by another connection in between (the dmarc-ingest
  process opens the same file) failed it at once with "database is locked"
  and the delivery line was lost. The first statement is now a write.
- R3: a delivery line updated every row of its queue id and recipient; it
  now updates only the newest (Postfix reuses short ids). The sweep closes
  by row id (QueuedDelivery.ID, CloseUnreported(id)).
- R4: a contradicted sweep keeps a mark, reason "reconcile-contradicted",
  instead of losing which row it was.
- R1: contradicted cannot see a lost line (never read late). New counter
  reconcile_missed: at close, the sweep looks for the row's delivery line
  in mail.log and mail.log.1 (QueueLines). 0007 edited - it has run on no
  database but throwaway stands.
- R2: queued_over_lifetime cannot measure "what removing the sweep would
  leave" while the sweep runs; its text now says rows stuck despite the
  sweep, and the rule uses closed - missed - contradicted.
- cert-reload (R5, R6, R7, security medium/low): both files copied to .new
  and the copies checked as a pair before both are renamed; acts on the copy
  only when postconf says Postfix reads it; a failed reload is retried next
  pass; umask 077; says so when the mounted files cannot be read. The e2e
  case asserts Postfix reads the copy, the copy equals the mount, the key is
  600 root.
- Security low: a recipient with a quoted local part - the journal cut
  "a b"@x at the space, deliveryRe cut "a>b"@x at the ">" - matched no
  delivery line and was closed by the sweep. cleanAddress ends a bracketed
  address at the first ">" outside quotes; deliveryRe takes the recipient
  up to the ">, " before relay= (test fixtures given the relay= every real
  delivery line has).
- Security low: postqueue -p's error carries at most 512 bytes of output.
- Nits: addDeliveryLogDay refuses a column not on its list; the truncation
  test checks its message.
- To stage 2b (page wording, mockup-first): the history step of a bounced
  row says the receiving server refused it, false for a row the sweep
  closed. To the owner when stage 2b is reached: since M13 the "deferred"
  figure counts whole messages too, which "Connections turned away" would
  not name.

Found while verifying: the e2e's main positive path failed once with "553
not owned by user app1" - an smtpd idle from before the panel's reload took
the connection in the reload's second. Measured on the stand (one-off
probe, not committed): sending 0, 10, 40, 110 s after the save (two seconds
at the soonest) always met an smtpd started after the reload. The e2e now
waits for the sender map after each application it creates
(waitForSenderMap: AUTH, MAIL, RCPT, RSET - no message, no row), and the
level-1 case uses it instead of its own loop.

Docs: architecture § Queue reconcile, schema-migrations (rows 7 and 8,
chain head 8), CHANGELOG, audit plan (stage 1 note, the measured window,
a new stage 2b line: 62 lines), roadmap 15/62.

Evidence on the test server for this tree: go vet clean, go test ./... 23
packages ok, make e2e exit 0 (renewed certificate, hung panel, level 1 at
49/60).

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

docs/audit-2026-10-12.md

@@ -584,7 +584,12 @@ has already run is never edited — the next file is added; the published
    from`. In the product this is a second or so after an application is
    saved in which its first message can get a permanent 553; not worth a
    change (an application is configured after it is created, not within the
-   second). The other cases are held to `451 4.7.1` (level 2, both MAIL FROM
+   second). *Measured 2026-10-14:* applications created and used after 0,
+   10, 40 and 110 s of waiting (the first send two seconds after the save at
+   the soonest) were all served by an smtpd started after the reload; the
+   stale one only ever answered within the reload's own second. The e2e
+   waits for the map after each application it creates (`waitForSenderMap`),
+   after the main positive path failed on it once. The other cases are held to `451 4.7.1` (level 2, both MAIL FROM
    of one connection), `553` at RCPT (sender mismatch), `554 … Client host
    rejected` at RCPT (no AUTH, and the relay case, whose comment claimed
    `reject_unauth_destination` - on 465 the client restriction comes first;
@@ -621,6 +626,15 @@ has already run is never edited — the next file is added; the published
    explained by `tailer_blind` means fix the tailer and keep the sweep,
    otherwise `lost` or remove. Decide after 30 days of data, or sooner if
    `contradicted` is ever non-zero. — **Opus**
+   *Changed by the reviews of stage 1 (2026-10-14):* a fifth counter,
+   `reconcile_missed` - a closed row whose delivery line was in `mail.log` or
+   `mail.log.1` when the sweep closed it; `contradicted` alone cannot see a
+   lost line, which is never read late. `queued_over_lifetime` cannot show
+   "what removing the sweep would leave visible" while the sweep runs (those
+   rows are closed by then); it counts rows stuck despite the sweep, and what
+   removing it would leave is `closed - missed - contradicted`. A
+   contradicted row keeps the mark `reconcile-contradicted`. The rule reads
+   accordingly in architecture.md § Log tailer.
 - *Deferred until the data is in* (not a step yet): pausing the sweep while the tailer is
    not reading (publish "healthy" from `follow`, skip the sweep otherwise),
    and the rotation window (keep draining the old inode until it has not
@@ -747,6 +761,16 @@ order - each stands on the one before.
    sentence stays only for a row whose line was truly never written or is
    older than this change, and says that. Done when the e2e shows the stored
    line on the page of each of the three refusals. - **Opus**
+- [ ] **A message the sweep closed does not say the receiving server refused
+   it** (review of stage 1, 2026-10-14). The history step of a `bounced` row
+   reads "the receiving server refused the message permanently, or Postfix
+   gave up ... The reason is in the delivery log below"
+   ([handlers_monitor.go](../internal/web/handlers/handlers_monitor.go)); for
+   a row with reason `reconcile` neither is known and the log has nothing.
+   Such a row gets its own step: Postfix no longer held the message and
+   `mail.log` never said what became of it, so the panel closed it as a
+   failure. Wording in the mockup `out-message` first (`design:` commit),
+   with the box of the step above. - **Sonnet**
 - [ ] **A refusal the panel did not get to write is written from
    `mail.log`** (owner, 2026-10-13, from the Not done list of
    from-header-binding; built on the step above). The check answers 550 and
@@ -775,7 +799,13 @@ order - each stands on the one before.
    becomes *Connections turned away*. Postfix refuses from the connection on
    while the check does not answer, before any message is offered, so a
    client that connects three times with one message is three, and a monitor
-   that only connects is one; messages cannot be counted. The mockup `health`
+   that only connects is one; messages cannot be counted. *To ask the owner
+   when this step is reached (2026-10-14):* since the M13 fix the figure
+   also counts whole messages - one a panel that hangs mid-message makes
+   cleanup defer (one per message, with a queue id) - so "Connections turned
+   away" would be half true; my recommendation: "Turned away" with the help
+   saying it counts connections refused at the start and messages deferred
+   in the middle. The mockup `health`
    and help topic `sender-check` first (`design:` commit), then the page and
    `view/help.go`, word for word. - **Sonnet**
 - [ ] Docs: architecture § Log tailer (the rotated file, the saved place, a