test: 补齐短时间可测验收并修复建群下行卡住

docs/DEVIATIONS.md

@@ -1062,3 +1062,33 @@
    - 原因：避免四份说明与 SDK 线漂移。  
    - 备选方案：在 docs/ 再建 SDK 汇总页。  
    - 影响：无。
+
+### Q accept-rest（补齐短时可测验收）2026-09-30
+
+1. **补测 F03/F04/F07/F10/F11/F14/F15/F18；F19 引用既有 SDK 清单**  
+   - 原条款：PRD 第 10 节；总控要求跳过 1000×10min、Linux netem 20%、1000 端全表 1s。  
+   - 实际做法：`test/accept/rest_accept_test.go` 用随机端口与临时目录；`grace_seconds`/`ack_timeout_seconds` 调到数秒；`record_retention_days=0` 另起进程；F19 对照表改为通过并写明四套 SDK checklist 证据路径，本波不重跑全量。  
+   - 原因：短时可测项应收口；长时/环境限制项不假装通过。  
+   - 备选方案：专用压测机与 Linux 宿主再补长时项。  
+   - 影响：`ACCEPTANCE.md` 汇总通过 23 / 失败 0 / 未测 0；长时子项仍写在备注。
+
+2. **harness MQTT 握手后清除 SetDeadline**  
+   - 原条款：`test/harness` 属总控；Dial 时 `SetDeadline(now+timeout)`。  
+   - 实际做法：WebSocket 升级成功与 TCP dial 成功后 `SetDeadline(time.Time{})`，避免长会话在 dial timeout 到期后读写全部失败。  
+   - 原因：F10 等短宽限仍需跨数秒保持连接；未清 deadline 时旧 10s dial 会在会话中途使 Recv 失败，表现为 `timeout waiting resp`。  
+   - 备选方案：每次读写刷新 deadline（更繁琐）。  
+   - 影响：跨线改了 harness；行为仅更正测试客户端，不改产品。
+
+3. **F15 带密建群用独立短生命周期进程**  
+   - 原条款：拉进群须当次带对话密码。  
+   - 实际做法：主会话用 `group.create` 无密断言失败；带密成功在干净进程上立刻建群。  
+   - 原因：与第 4 条同一死锁，补测时先用隔离进程覆盖校验路径。  
+   - 备选方案：仅依赖第 4 条修复后在同一长会话上测 `group.add`。  
+   - 影响：验收覆盖仍成立。
+
+4. **群事件 `emit` 改为异步 PublishDown**  
+   - 原条款：群变更向成员推 `group_event`（QoS 0）。  
+   - 实际做法：`internal/app/group/app.go` 的 `emit` 在独立 goroutine 里延迟约 20ms 再 `PublishDown`，让上行 worker 先把 `resp` 推完。  
+   - 原因：同一连接上 `group.create`/`group.add` 同步向本连接注入下行时，与 mochi InlineClient 互相等待，`resp` 回不去（`TestUplinkDMOfflineGroupRecall` 在清掉测试客户端 dial deadline 后稳定复现）。  
+   - 备选方案：broker 层对 Inline 发布做无锁队列。  
+   - 影响：`group_event` 可能略晚于 `resp` 到达；业务结果仍以 `resp` 为准。