修正: 上一笔把「成员换了」写成了实测 —— 「哪一行进来」是**推断**，mails 表没有 updated_at

`cc4db68` 里我写「1494154f 被补标（-1）、c416c98e 新漏（+1），净额 0 ⇒ 池子换了两个人」，
读起来像两条都是读数。**其中第二条我证明不了。**

- **可证**：`1494154f` 04:33:34 排末位 5/5（漏标）→ 06:00:46 拿到 `read_at`（排 3/10）
  ⇒ 它**确实离开了缺口**（-1）。
- **可推**：40 → 40 而确有 1 行离开 ⇒ **必然有 ≥1 行在同一窗口进入**。
- **不可证**：**哪一行进来了**。`mails` 表**没有 `updated_at`**
  （列只有 `status` / `created_at`）⇒ 缺口的历史成员集合**无法重建**。
  `c416c98e` 是最可能的候选（同期在末位 10/10 漏标、`status='read'`、`mail_reads` 零行），
  但那是**推断不是读数**。

⇒ docs 里已改成三段式（可证 / 可推 / 不可证），并点名"最可能是 c416c98e，但这是推断"。
结论（缺口是流量不是库存、不能只数总数）不受影响 —— 它只依赖"-1 确实发生"这一条，
而那条是实测的。

同族第 4 次：**把"我推出来的"写成"我量到的"。** 前三次是 133 个文件 / 107-81 /
PATH shim 的 in_use 理由。

docs/API.md

@@ -481,9 +481,18 @@ curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"
   在 04:33:34 排**第 2 位 ⇒ 标上**。同一封信、只换位置、结果相反 —— 因果钉在**批次位置**上。
 
   ⚠️ **由此得到一条容易看错的教训：缺口是"流量"不是"库存"。**
-  回填前的缺口**连续两次量都是 40 行**，看着像个稳定常数，会让人得出"可以等部署"的结论；
-  但**成员每天都在换**：同一天里 `1494154f` 被补标（-1）、`c416c98e` 新漏（+1），
-  净额为 0 ⇒ 总数不变而**池子换了两个人**。
+  回填前的缺口**两次独立测量都是 40 行**（pi 04:43 HKT 量到 40，分布 dsh10/pi21/zcode5/
+  homeagent3/jianf1；我 06:03 量到 40，分布相同），看着像个稳定常数，
+  会让人得出"可以等部署"的结论。**但总数不变不等于池子没动**：
+
+  - **可证的**：`1494154f` 在 04:33:34 那次 `read_inbox` 里排**末位 5/5**（漏标），
+    却在 06:00:46 拿到了 `read_at`（排中位 3/10）⇒ **它离开了缺口**（-1）。
+  - **由计数推得的**：既然 40 → 40 而确有 1 行离开，就**必然有 ≥1 行在同一窗口进入**。
+  - **不可证的**：**哪一行进来了**。`mails` 表**没有 `updated_at`**（列只有
+    `status` / `created_at`）⇒ 无法重建缺口的历史成员集合。
+    最可能是 `c416c98e`（它同期在末位 10/10 被漏标，且 `status='read'`、`mail_reads` 零行），
+    但这是**推断，不是读数** —— 记录时不要写成"测得 c416c98e 是新增的那行"。
+
   ⇒ 判"还欠多少"不能只数**总数**，要数**成员集合**（或直接看部署了没有）。
   **一个稳定的计数可以掩盖一个持续在发生的错误。**