改: 我一直量的是**代理量** —— 真实重投面是 unreadFor（只读 mail_reads），不是 mails.status='unread'

发现路径：向 pi 解释 `4→8→2` 时去核 `?status=unread` 到底挂在哪一列，读到：

    repo.go:611  if status == "unread" { q += ` AND ` + unreadFor("$1") }   // :612
    repo.go:488  func unreadFor(arg) = (m.status <> 'archived' AND NOT EXISTS(
                     SELECT 1 FROM mail_reads r WHERE r.mail_id=m.mail_id AND r.reader_name=arg))

⇒ **真实判据只看 `mail_reads`，`mails.status` 完全没参与。**
⇒ "`m.status='read'` 但 `mail_reads` 无行"**同样在重投面内**（那正是 40 行 gap 的成因）
⇒ 而我上面所有"会 `catchUp` 重投"的数都拿 `m.status='unread'` 筛的 ⇒ **系统性少算**。

一次计算内实测（join 非 archived ∧ 有真孩子）：

    真实（unreadFor 口径）        = 92
    我的代理（status='unread'）    = 77
    代理漏掉（status='read' 无行） = 15
    加法自洽 77 + 15 = 92 = 直接算  ✓

★ 这又是本仓那条 **"判据必须读决定行为的那个列"**，方向相反而已：
上次是**测试**读错列（守冗余列 ⇒ 守不住 bug），
这次是**我自己**读错列（拿冗余列当筛选 ⇒ 量小重投面）。
**两处错的是同一个东西：把 `mails.status` 当权威。**

docs/API.md

@@ -658,6 +658,38 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   "收件人回过"只是**充分**证据，真实漏记量 **≥** 该判据命中数）。
   **"补完 40 行"与"历史账平了"是两件事** —— 这正是本节开头那条"A 对不代表 B 对"的同一个形状。
 
+  ★★★ **"重投面"我一直量的是代理量，不是真实量（2026-09-21 发现并改正）**：
+  上面所有"会出现在 `?status=unread`、会被 `catchUp` 选中"的数，
+  我都用了 `mails.status='unread'` 作筛选 —— **但线上判据根本不看那一列**：
+
+  ```go
+  // server/internal/repo/repo.go:611
+  if status == "unread" { q += ` AND ` + unreadFor("$1") }   // :612
+  // :488
+  func unreadFor(arg string) string {
+      return `(m.status <> 'archived' AND NOT EXISTS (
+          SELECT 1 FROM mail_reads r WHERE r.mail_id = m.mail_id AND r.reader_name = ` + arg + `))`
+  }
+  ```
+
+  ⇒ **真实判据 = `mail_reads` 里有没有"我这个读者"的行**（外加"非 archived"），
+  **`mails.status` 完全没参与。**
+  ⇒ 于是"`m.status='read'` 但 `mail_reads` 无行"**同样在重投面内** —— 那正是那 40 行 gap 的成因。
+  ⇒ 我一直报的那一档**只是它的真子集**。一次计算内实测（`join` 非 archived ∧ 有真孩子）：
+
+  ```
+  真实集合（unreadFor 口径）                    = 92
+  我的代理（m.status='unread' 那一档）           = 77
+  代理漏掉的一档（m.status='read' 但权威列无行）  = 15
+  加法自洽：77 + 15 = 92 = 直接算的 92  ✓
+  ```
+
+  ⇒ **凡我说"重投面有 N 封"，都系统性少算了"`status='read'` 而权威列无行"那一档。**
+  ⇒ 这又是本节那条 **"判据必须读决定行为的那个列"** —— 只不过方向相反：
+  上次是**测试**读错了列（读冗余列，守不住 bug），
+  这次是**我自己**读错了列（用冗余列当筛选，量小了重投面）。
+  **两处错的是同一个东西：把 `mails.status` 当成了权威。**
+
   ★ **而且这不是"历史账"问题，是活的重投源**：严格口径下那批里有相当一部分
   （宽松口径时量到 **85 封**，同样会漂）在 `sessions.status <> 'archived'` 的会话里
   ⇒ **会出现在 `?status=unread` 里、会被 `catchUp` 选中重投**