任务状态查询本身带上退避重试，瞬时故障不再作废一次计费任务

- platform-tripo：`get_task` 内部按 `TripoSettings::retries` 对瞬时故障（连接抖动 / 超时、408、429、5xx）退避重试，确定性失败（任务 id 非法、响应结构不符、404）立即返回；重试字段与退避函数改名，不再只服务产物下载
- api-server worker：查询在重试后仍是瞬时故障时继续按轮询间隔查到预算用尽，只有确定性失败才立刻收口
- 新增用例：一次 500 后成功（重试生效）、404 只打一次请求（不重试），并给测试客户端加了可指定 base_url 的构造
- docs/technical：写明查询带退避重试与「确定性失败立即返回」的边界

docs/technical/【技术方案】Tripo 3D模型Provider集成-2026-09-18.md

@@ -44,7 +44,7 @@ TODO：图生输入当前由 api-server 自己读站内对象的字节再上传
 
 ## 任务查询与下载
 
-`get_task` 按 `TripoTaskHandle` 做单次查询，返回通用 `TripoTaskSnapshot`，由 `task_type` 决定 `output` 的具体 variant；adapter 不做轮询、不阻塞等待。
+`get_task` 按 `TripoTaskHandle` 做单次查询，返回通用 `TripoTaskSnapshot`，由 `task_type` 决定 `output` 的具体 variant；adapter 不做轮询、不阻塞等待。单次查询内部带退避重试：生成本来要跑几分钟，一次连接抖动不该作废一笔已经提交、不能重来的计费任务，所以瞬时故障（连接抖动 / 超时、408、429、5xx）按 `TripoSettings::retries` 重试，确定性失败（任务 id 非法、响应结构不符、404）立即返回。
 
 `download_model`（及预览图的 `download_rendered_image`）接受 `TripoTaskSnapshot` 与调用方给的体积上限 `max_bytes`，先确认快照确实处于完成态，再从严格 endpoint 结果中取得已校验的产物地址，由 provider 自己的无鉴权 reqwest client 打开签名 URL，读完整个 body 后返回 `TripoArtifactBytes`（`url`、`content_type`、`content_length`、`bytes`、`filename(name)`）。流式句柄 `TripoDownloadedArtifact`（`next_chunk()`）保留为内部实现：**重试必须包住整个 body** —— 只重试「拿到响应头」这一步的时候，几十 MB 的字节其实是在之后才传输的，一次 CDN 抖动就会毁掉一次已经扣费、provider 任务也跑完的生成。因此每次尝试都重新取响应头并整体重下（不做断点续传，签名地址会过期），body 读取失败与长度不一致都归一成可重试的传输错误，重试上限与退避沿用 `TripoSettings::retries`。**可重试性由产生错误的一方显式判定，不再由「`status` 是不是 `None`」推断**：传输层的超时 / 连接失败、「无数据推进」超时、body 提前结束都可重试；客户端构造失败、响应体格式错误（空 body / 缺 `data` 字段）、DNS 与 TLS 之外的永久失败不可重试 —— 只看 `status.is_none()` 会把这两类混在一起，把故障拖到重试耗尽才暴露。`filename(name)` 的扩展名来自远端地址，只接受短的 ASCII 字母数字，其余退回 `glb`，避免远端地址里的 `%2F` 解码后拼出跨目录路径。每次读取都校验实际接收字节数与 `Content-Length`，读到 `max_bytes` 之上直接按输出违约失败（不重试）：宁可失败退款也不要把 api-server 内存打满。产物下载不设总超时：几十 MB 的流只要还在出数据就不该被判失败，重下只发生在传输真的断了的时候，因此下载链路只按「无数据推进」判超时，预算取 `TripoSettings::request_timeout`（连接用 `connect_timeout`，响应体用 `read_timeout`，响应头之前由显式的 `tokio::time::timeout` 兜住），超过预算没有数据推进即按传输失败返回；SDK 保持第三方原样，不承担产物下载。smoke example 一次写入完整字节；未来接入 OSS 时应把同一数据流直接送入 OSS 分片上传，不经过完整内存缓冲。