docs(审查): 给 push 报告 §二.1 补修复状态（pi 现场标注）

pi 在 `[收尾验证]` 那封邮件驱动的一轮里，独立复核出 `044a664` 的
commit message 承诺「挪到确认能发之后」而 diff 只改了传参 ——
**调用位置仍在 accessToken 之前**，注释与代码自相矛盾。

它在这份报告上就地标了修复状态。三点值得留在文档里：

  ① ①（按批次计）真修了且有判据；② 当时**只写进注释、代码没动**。
  ② 之所以没被当场发现：当时那批判据**造不出「accessToken 失败」这条路**
     （`hmsStub` 的 `/token` 永远返回 200 + 令牌）。
  ③ 现已真正落地，并补判据；把修复回退后判据会红。

★ 教训值得单列：**「我写了注释说明怎么修」不等于「我改了代码」**。
审查报告给了两条，我处理了一条，把另一条誊进注释就当做了。
写完注释应当立刻核对行号 —— 那是 5 秒钟的事。

docs/reviews/push-and-gui-review.md

@@ -58,6 +58,17 @@ tok, err := h.accessToken(ctx)   // ← 额度已经扣了
 **修法**：`reserveDaily(1)`（按批次计），并把预留挪到**确认拿到 access_token 之后**、
 或失败时归还。
 
+> **修复状态（2026-09-28）**：① 已修（`044a664`，`reserveDaily(1)`，有判据
+> `TestHMSDailyLimitCountsMessagesNotTokens`）。
+> ② **曾被声称已修但没落地** —— `044a664` 的 commit message 承诺「挪到确认能发之后」，
+> diff 里却只改了传参，**调用位置仍在 `accessToken` 之前**，注释与代码自相矛盾。
+> 之所以没被当场发现，是因为当时那批判据**造不出「accessToken 失败」这条路**。
+> 现已真正落地（预留移到 `accessToken` 成功之后、发请求之前），
+> 并补上判据 `TestHMSAccessTokenFailureDoesNotBurnQuota`：
+> 把修复回退后该判据**失败**（`accessToken` 失败 3 次 → `dayCount=3`），
+> 修复在位则 `dayCount=0`。抓住这处不一致的是 pi。
+
+
 ### 2.【HIGH】HMS 通知载荷缺 `click_action`，锁屏点击可能带不出 `data`
 
 `hms.go:206-217`：