feat: add crm dead-letter operations and benchmark summary

docs/refactor/taro-frontend-integration.md

@@ -3164,7 +3164,7 @@ GET /api/ai/school-recommendations/export?reportId=<reportId>&format=html
 - 勋章：`GET/PUT /api/tenant-admin/badges`、`GET/POST /api/tenant-admin/badge-grants`
 - 考试日期：`GET/PUT /api/tenant-admin/exam-dates`
 - 题目反馈：`GET /api/tenant-admin/feedbacks`、`GET /api/tenant-admin/feedbacks/report`、`POST /api/tenant-admin/feedbacks/status`、`GET /api/tenant-admin/feedbacks/events`
-- 销售/代理/CRM 队列、CRM 配置、CRM 跟进分配策略、分佣规则、成员分佣比例、分佣订单、结算单审核和线下打款登记；当前 Taro 租户营销中心已接 CRM、分佣、优惠券规则和核销报表第一版，财务运营页已接退款、官方账单、对账异常、差错工单和调整凭证第一版。真实打款 provider、发票、生产账单抽样验收和更完整财务复核体验后续增强。
+- 销售/代理/CRM 队列、CRM 配置、CRM 跟进分配策略、CRM 死信失败池、脱敏日志、手动重试/忽略、分佣规则、成员分佣比例、分佣订单、结算单审核和线下打款登记；当前 Taro 租户营销中心已接 CRM 配置、队列、死信失败池、日志、重试/忽略、分佣、优惠券规则和核销报表第一版，财务运营页已接退款、官方账单、对账异常、差错工单和调整凭证第一版。真实打款 provider、发票、生产账单抽样验收和更完整财务复核体验后续增强。
 
 CRM 分配策略由后端执行，前端只提交配置：
 
@@ -3177,6 +3177,16 @@ CRM 分配策略由后端执行，前端只提交配置：
 
 `assignmentMode` 支持 `none`、`direct`、`round_robin`、`referrer`。后端会校验 `assignmentPool` 中的用户必须是当前租户内 active 的销售、代理、运营、教师或管理员；跨租户成员会返回 `CRM_ASSIGNMENT_POOL_INVALID`。首绑客资成功后，`lead.item.assignedToUserId` 是 CRM 跟进负责人，`lead.item.referrerUserId` 仍是受首绑保护的推广/分佣归属，两者不要在前端混用。CRM 队列 `payload.assignee` 可用于展示推送目标，但前端不能自行改写客资归属或分配游标。
 
+CRM 死信运营统一走后端命令层：
+
+```text
+GET  /api/crm/dead-letters
+GET  /api/crm/queue/logs?queueId=<crmQueueId>
+POST /api/crm/queue/action
+```
+
+前端只展示后端返回的脱敏 payload/log，不能从日志里拼 webhook URL、secret 或 token。`retry` 用于 webhook 恢复后重新入队，`ignore` 用于租户确认不再处理的失败任务；按钮需要二次确认并要求填写原因，后端会记录操作者和审计。`pending/processing/sent` 任务不能被忽略，前端应按接口错误提示展示，不做本地状态覆盖。
+
 租户后台不应在前端自行决定权限；隐藏菜单只是体验优化，接口仍会校验权限。角色模板用于让租户配置“运营、教师、销售、代理”等自定义后台体验，成员绑定模板后，前端按模板的菜单/模块/字段权限渲染，后端按 permission keys 执行真正的访问控制。班级/学生范围权限由后端根据角色、模板 `dataScope.classIds` 和 `tenant_class_members` 计算，教师默认只能看到自己负责班级。
 
 ## 联调顺序