feat(ai-title): 标题生成读取超时改用 4K 档 600 秒 (§19.30)

标题是「一次请求·纯提示词·生成多条」，需经中转站转发 + 大模型排队 +
整段返回，比一张图更耗时。原借 1K 档 240 秒读取超时，慢/排队型模型常在
返回前 ReadTimeout。改为借 4K 档 600 秒（resolution_timeout 512/1K/2K/4K →
180/240/360/600s），仅改标题链路，不动 generate_texts 默认 1K；模型条目
timeout_seconds>0 仍优先覆盖。

- ai_title.py：加常量 _TITLE_TIMEOUT_RESOLUTION="4K"，generate_titles
  显式传 resolution 借 600s
- docs/11 §17.2 补读取超时说明、新增 §17.8 决策
- tests/test_ai_title：断言以 resolution="4K" 调 generate_texts
- tasks.md：新增 §19.30；同时含 match_stamp §19.30–§19.34 任务段的移除
  （用户回退 match_stamp 功能，本提交仅移除其 tasks.md 段落）

验证：test_ai_title / test_ai_text_service + 全套 py37（232 测试）通过，
唯一失败为无关的 test_config_service packaging 模板；离屏冒烟确认读取超时
=600s、timeout_seconds>0 优先覆盖。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/11-ai-outfit.md

@@ -464,6 +464,7 @@ Excel 行 → `OutfitTask` 列表的转换由 `excel_service` 完成；核心只
   - 一次 POST → `extract_titles_from_response` 返回**多条**清洗后标题。
 - `generate_text(prompt, image_path=None) -> str`：保留（返回第一条，= `generate_texts` 的 `[0]`），供单条场景与既有单测；与 `generate_texts` 共用同一段 POST。
 - `extract_titles_from_response(data) -> List[str]`：取 `choices[0].message.content` / gemini `candidates[0].content.parts[].text` 的原始文本，**按逗号（`,`/`，`，兼容换行）拆分 + 逐段清洗**（去首尾空白/序号/符号/引号、丢空），返回标题列表（§19.23）。`extract_text_from_response` = 取其首条（兼容保留）。
+- **读取超时：标题生成走 4K 的 600 秒（§17.8）**。`generate_texts`/`generate_text` 的 `resolution` 形参本是图像分辨率借来的超时档（`resolution_timeout`：512→180 / 1K→240 / 2K→360 / 4K→600 秒）；纯文本请求没有"分辨率"，只借那张超时表。`generate_titles` 显式传 `resolution="4K"`（`ai_title._TITLE_TIMEOUT_RESOLUTION`）→ 读取超时 **600 秒**，而非默认档 1K 的 240 秒。理由：一次请求要中转站排队、大模型生成多条标题再整段返回，240 秒对慢模型/排队偏紧。连接超时仍 30 秒不变；模型条目若显式设 `timeout_seconds>0` 仍**优先覆盖**这 600 秒（`_post`：`config.timeout_seconds if >0 else resolution_timeout(resolution)`）。
 
 ### 17.3 模型与提示词
 
@@ -514,3 +515,12 @@ Excel 行 → `OutfitTask` 列表的转换由 `excel_service` 完成；核心只
 - **条数对不上不强求**：`N>行数` 多的丢、`N<行数` 后面行留空 + 日志，不报错中止（用户可改提示词数量重跑）。
 - **代价**：标题不再与具体某件衣服一一对应（无图）；若将来要"每件看图各出标题"，那是另一种模式，按 §17.1 旧版思路另做。
 - 文本服务保留 `generate_text`（单条）+ 新增 `generate_texts`（多条），共用同一段 POST；标题流程走 `generate_texts(prompt, image_path=None)`。
+
+### 17.8 决策：标题生成读取超时用 4K 档（600 秒）
+
+标题生成默认读取超时从 **1K 的 240 秒改为 4K 的 600 秒**（§19.30）。
+
+- **背景**：标题是"一次请求、纯提示词、生成多条"（§17.7）。这一次请求要经中转站转发、大模型排队、生成 N 条标题后**整段**返回；比"一张图"耗时更不可控（推理/排队型模型尤甚）。原先借用 1K 档 240 秒，偏紧，慢模型会在拿到结果前就 `ReadTimeout`。
+- **改法**：`generate_titles` 显式传 `resolution="4K"`（常量 `ai_title._TITLE_TIMEOUT_RESOLUTION`），把读取超时抬到 600 秒。**只改标题这一条链路**——`generate_texts`/`generate_text` 的默认 `resolution="1K"` 不动，其它/未来调用方不受影响。
+- **为什么复用分辨率档而非新增字段**：纯文本请求本无分辨率，`resolution` 只是 `resolution_timeout` 那张 `{512/1K/2K/4K → 180/240/360/600}` 超时表的键；复用它零新增配置、与图片侧同一套超时语义，最省。若将来要独立可调，再在模型条目上用 `timeout_seconds>0` 覆盖（已支持，优先级高于分辨率档）。
+- **代价**：慢/挂死的请求现在最长等 600 秒才失败（而非 240 秒），但标题生成是单次、手动触发、非批量循环，多等的是最坏情况，正常返回不受影响。