docs(审查): 补上 pi 建议的第二格判据（pi 又改了一次它自己的标注）

上一提交只写进了一格判据，pi 随后把它的建议补上 —— 报告里现在是两格：

  · `TestHMSAccessTokenFailureDoesNotBurnQuota`          钉内部计数器 dayCount==0
  · `TestHMSQuotaSurvivesTokenFailureWithLimitOne`       钉用户看得见的行为

两层都要钉的理由：**计数器对而行为错是可能的** ——
运维会收到「达到每日推送上限」这种**误导性文案**，
而真实原因只是上一次网络抖动。这正是它建议单独加一格的原因。

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

@@ -64,9 +64,15 @@ tok, err := h.accessToken(ctx)   // ← 额度已经扣了
 > diff 里却只改了传参，**调用位置仍在 `accessToken` 之前**，注释与代码自相矛盾。
 > 之所以没被当场发现，是因为当时那批判据**造不出「accessToken 失败」这条路**。
 > 现已真正落地（预留移到 `accessToken` 成功之后、发请求之前），
-> 并补上判据 `TestHMSAccessTokenFailureDoesNotBurnQuota`：
-> 把修复回退后该判据**失败**（`accessToken` 失败 3 次 → `dayCount=3`），
-> 修复在位则 `dayCount=0`。抓住这处不一致的是 pi。
+> 并补上两格判据：
+> - `TestHMSAccessTokenFailureDoesNotBurnQuota` —— 钉**内部计数器**（`dayCount == 0`）
+> - `TestHMSQuotaSurvivesTokenFailureWithLimitOne` —— 钉**用户看得见的行为**
+>   （`DailyLimit=1` 时一次 `accessToken` 失败后第二次仍然要能发出去）
+>
+> 两层都要钉：计数器对而行为错是可能的 —— 那会让运维收到「达到每日推送上限」这种
+> **误导性文案**，真实原因却是上一次网络抖动。
+> 变异验证：把预留挪回 `accessToken` 之前，**两格同时红**。
+> 抓住这处不一致的是 pi。
 
 
 ### 2.【HIGH】HMS 通知载荷缺 `click_action`，锁屏点击可能带不出 `data`