把「已提交但没写下记录」的崩溃窗口写进文档

- docs/technical Tripo 集成方案：at-most-once submit 段新增「崩溃窗口（已知并接受，消不掉）」一条——submit 受理与 checkpoint 落库之间崩溃时库里没有任何记录，该窗口加判断消不掉；固定 max_attempts = 1 保证不会二次 submit / 二次计费，代价是这笔生成按失败退款、provider task id 也没留下
- docs/后端数据契约：provider checkpoint 那条把「重新 claim 一定能读到」的保证收窄为「checkpoint 已写下之后」，并指向集成方案的这一段

docs/technical/【技术方案】Tripo 3D生成API集成-2026-09-21.md

@@ -82,6 +82,8 @@ canvasCompletion? 画布占位框回填，只在项目资源落点下生效
 3. 已有 `providerTaskId` 的 job 只允许 `get_task`、下载与落库，绝不允许再次 submit；
 4. submit 成功但 checkpoint 写入失败的 attempt 只能终态失败，不得退回可重试队列，否则重试会二次 submit；该 job 保留脱敏对账信息供人工处理。
 
+**崩溃窗口（已知并接受，消不掉）**：submit 的真实顺序是「先向 provider 提交（不可撤销、已计费）→ 再把 provider task id 落成 checkpoint」，两步之间进程崩溃时，库里没有任何记录能证明这次提交发生过。这个窗口不能靠加判断消掉——写 checkpoint 这一步本身也可能失败或崩溃，多加一层只会把窗口挪个位置。当前的口径是：Tripo job 固定 `max_attempts = 1`，租约耗尽的 job 直接终态失败、不会被重新 claim，所以**不会二次 submit、不会二次计费**；代价是这一笔 provider 侧已经跑起来的生成没有结果可用（按失败收口并退款），而且连 provider task id 都没留下，人工对账也缺凭据，净亏损由平台承担。因此「重新 claim 一定能读到已提交记录」只在 checkpoint 已经写下之后成立，不能当成从 submit 那一刻起的保证；要缩小窗口只能改 provider 侧（让提交本身可重放，或先申请再提交这类两阶段流程），不在本方案的范围内。
+
 失败重试沿用现有语义：`fail` 先按 attempt 冲正扣费，`attempt < maxAttempts` 时回到 `pending` 并延迟重试，否则终态 `failed`。Tripo job 固定 `max_attempts = 1`，这条路径退化为“第一次失败即终态”，永不进入延迟重试。
 
 **provider 成功但落库失败按失败处理**：job 失败、该 attempt 退款，客户端看到 failed。没有正式资源引用就不算交付成功；checkpoint 保留，人工对账可证明这次生成确实发生过。由此产生的“provider 已消耗、用户已退款”净亏损是已知并接受的成本。