量: 那个"少标末位"的 bug **仍在生产活着** —— 13 次调用 13 次漏末位，且它自己制造重投

顺着 pi 的 `4→8→2` 追下去时，把本会话日志里**每一条会标已读的** `read_inbox`
（`status != 'all'`；`all` 按 `idsToMarkRead` 定义**故意不标**）与 `mail_reads` 的
**同 `read_at` 串**批次对齐，得到比原先 3 行更完整、也更硬的一组读数：

    13 次调用 → 列出 81 封 / 同批标上 68 封 ⇒ **少 13 封**
    漏的**永远是列出的最后一个**，13/13，零例外

（原本 docs 里只有 04:10/04:33/06:00 三次；现在补到 13 次，跨 09-18~09-21。）

## 一、★ 它仍在生产活着：修复没部署

`17908c1`（04:25:17）修的就是这个。但线上二进制 **mtime = 09-19 13:04**、进程启于 09-20 04:01
⇒ **跑的还是旧代码**。09-21 的 5 次里**有 4 次在提交之后**，症状照旧。
⇒ **"修好了" ≠ "生效了"。**（04:10:57 那次在提交**之前**，不能当反例 —— 我初稿写成
"5 次全在提交之后"，复核时自己抓到。）

## 二、★★ 这个 bug 会**自己制造重投**（因果链，9/12 直接命中）

漏标的末位**仍算未读** ⇒ **紧接着的下一次 `read_inbox` 又把它列出来**：

    09-18 04:43 漏 2800c865 ⇒ 04:55 又列出 ✓   …（共 9 条直接命中）
    其余 3 次因换会话/中断未在紧邻调用里复发

本会话日志里同一封被重复列出过的共 **27 封**，其中 **12 封**正属于"被漏标"这批。
⇒ **重投不是另一个 bug，它就是漏标的直接后果。**
（这也回过头解释了 pi 观测到的 `4→8→2`：**收缩**来自 read_inbox 批量扫走，
而**膨胀**里有一部分是我上一轮漏标留下的。）

## 三、★ 我的读数方法自己纠正过我一次

第一版用"秒级窗口"匹配 ⇒ 得到 12 次漏末位 + **1 次"全标上"的假例外**。
改用**同 `read_at` 串**（一次 `POST` 的所有插入共享同一条 `strftime(...,'now')`）
⇒ 例外消失、**13/13 全部漏末位**。
⇒ **读数方法不严，会把一个完美一致的信号读成一个有噪声的信号** ——
而"有噪声"会让人放弃追查。我又差点因此把 13/13 记成 12/13。

## 四、顺带的算术自洽

表内 `列出 81 − 标上 68 = 13 = 漏标次数`（每次恰漏 1 封）—— 与"总数守恒"同族的免费交叉验证。

docs/API.md

@@ -471,15 +471,57 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   因为**线上跑的还是有 bug 的二进制**（构建于 09-19 13:04，早于 `f2063e1`）。
   形态与离线探针**逐字一致**——`read_inbox` 列 N 封、**只标上 N-1 封，漏的永远是末位**：
 
-  | 调用 | 列出 | 同刻标上 | 末位 |
+  | 调用(HKT) | 列出 | 同批标上 | 漏的末位 |
   |---|---|---|---|
-  | 04:10:57 | 5 | 4 | `474323c3` 漏 |
-  | 04:33:34 | 5 | 4 | `1494154f` 漏 |
-  | 06:00:46 | 10 | 9 | `c416c98e` 漏 |
+  | 09-18 04:43:05 | 3 | 2 | `2800c865` |
+  | 09-18 04:55:20 | 10 | 9 | `4f702d7c` |
+  | 09-18 05:06:56 | 6 | 5 | `85586f9b` |
+  | 09-18 05:07:14 | 11 | 10 | `bc6817c9` |
+  | 09-18 07:43:25 | 3 | 2 | `63ff976a` |
+  | 09-19 12:43:03 | 5 | 4 | `70ad57d3` |
+  | 09-19 12:57:15 | 3 | 2 | `63ff976a` |
+  | 09-20 04:06:28 | 10 | 9 | `fe9b830c` |
+  | 09-21 04:10:57 | 5 | 4 | `474323c3` |
+  | 09-21 04:33:34 | 5 | 4 | `1494154f` |
+  | 09-21 06:00:46 | 10 | 9 | `c416c98e` |
+  | 09-21 06:39:22 | 6 | 5 | `e427d928` |
+  | 09-21 07:02:20 | 4 | 3 | `5ff4318c` |
+  | **合计** | **81** | **68** | **少 13** |
+
+  **口径**：只取 `status != 'all'` 的调用（`all` 按 `idsToMarkRead` 的定义**故意不标**）；
+  "同批"= `mail_reads` 里 `read_at` **字符串完全相同**的那一组
+  （一次 `POST` 的所有插入共享同一条 `strftime(...,'now')`）。
+  **13 次调用、13 次漏末位，零例外。**
+
+  ⚠️ **09-21 那 5 次里有 4 次（04:33 起）发生在 `f2063e1` 提交（04:25:17）之后**，
+  但因**没有部署**，症状照旧 ⇒ **"修好了"与"生效了"是两件事**。
+  （另：04:10:57 那次在提交**之前**，本来就不该指望它修好 —— 不能拿来当反例。）
+
+  ★ 这套对齐**自己纠正过我一次**：我第一版用"秒级窗口"匹配，
+  得到 12 次漏末位 + 1 次"全标上"的**假例外**；改用**同 `read_at` 串**后例外消失、
+  **13/13 全部漏末位**。⇒ **读数方法不严，会把一个一致信号读成有噪声的信号。**
 
   **跨调用同信同位对照**（最强的一档）：`474323c3` 在 04:10:57 排**末位 ⇒ 漏**，
   在 04:33:34 排**第 2 位 ⇒ 标上**。同一封信、只换位置、结果相反 —— 因果钉在**批次位置**上。
 
+  ★★ **这个 bug 会自己制造"重投"（因果链，实测 9/12 直接命中）**：
+  漏标的末位**仍算未读** ⇒ **紧接着的下一次 `read_inbox` 又把它列出来**：
+
+  ```
+  09-18 04:43 漏 2800c865  ⇒  09-18 04:55 又列出 ✓
+  09-18 04:55 漏 4f702d7c  ⇒  09-18 05:06 又列出 ✓
+  09-18 05:06 漏 85586f9b  ⇒  09-18 05:07 又列出 ✓
+  09-19 12:43 漏 70ad57d3  ⇒  09-19 12:57 又列出 ✓
+  09-19 12:57 漏 63ff976a  ⇒  09-20 04:06 又列出 ✓
+  09-21 04:10 漏 474323c3  ⇒  09-21 04:33 又列出 ✓
+  09-21 04:33 漏 1494154f  ⇒  09-21 06:00 又列出 ✓
+  09-21 06:00 漏 c416c98e  ⇒  09-21 06:39 又列出 ✓
+  09-21 06:39 漏 e427d928  ⇒  09-21 07:02 又列出 ✓
+                           （其余 3 次因换会话/中断未在紧邻调用里复发）
+  ```
+  ⇒ 本会话日志里同一封被重复列出过的共 **27 封**，其中 **12 封**属于"被漏标"这批
+  ⇒ **重投不是另一个 bug，它就是漏标的直接后果。**
+
   ⚠️ **由此得到一条容易看错的教训：缺口是"流量"不是"库存"。**
   回填前的缺口**两次独立测量都是 40 行**（pi 04:43 HKT 量到 40，分布 dsh10/pi21/zcode5/
   homeagent3/jianf1；我 06:03 量到 40，分布相同），看着像个稳定常数，