docs: add T-546 cmhub shared Session + connection pool + proxy handling

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

docs/06-tasks.md

@@ -137,6 +137,7 @@
 | T-535 | ② cmhub 生成标题读取等待固定 600 秒 | T-526, T-533 | 问题：当前 cmhub 生文请求的读取等待时间复用 `ai.resolution_timeouts`，会跟随当前分辨率变化；默认 `1k=240s`，若上游模型排队或响应较慢，标题生成容易先超时。方案：cmhub `gen_title()` 的 `title_request` 读取等待固定使用 600 秒（等同 4k 上限），不再跟随当前分辨率；连接超时仍使用 `ai.cmhub.connect_timeout`，重试次数仍使用 `ai.retry`。2026-07-07 补充：cmhub 生图请求与图片下载读取等待统一固定 650 秒，读超时仍不自动重发；⑤设置页「返回超时」标签在普通默认 cmhub 模式下展示「标题 600 秒 / 图片 650 秒」，避免用户误以为分辨率下拉仍会改变 cmhub 等待时间；direct 兼容路径保持现状。补 `tests/test_ai.py` 断言标题请求 timeout 为 `(connect_timeout, 600)`、生图请求和下载 timeout 为 `(connect_timeout, 650)`，补 `tests/test_gui.py` 断言 cmhub 标签固定展示实际口径、direct 仍展示分辨率映射；不改配置 schema、cmhub HTTP 协议、DB、Excel 或 Shopee/CDP | DONE |
 | T-545 | ② cmhub 生图和下载并发上限 5 + 独立下载线程池 | T-535, T-533, T-519 | 背景：实测 10 图片并发时，cmhub 后台单条生成小于 200 秒，但本地下载 `/media/generated/images/*.png` 常见 24~185 秒且有连接失败；如果每个生图线程同时负责“等待 cmhub 返回 + 下载 + 转 JPEG + 保存”，下载慢会占住生图线程，后续任务排队。方案：cmhub 模式下实际生图请求并发 = `min(ai.image_concurrency, 5)`；拿到 `image_url` 后把下载/转 JPEG/保存交给独立下载线程池，下载线程数与实际生图请求并发一致、同样最大 5；不新增用户可见配置项，⑤仍只保留「图片并发」。②开始日志必须显示用户设置图片并发、cmhub 实际生图并发和下载并发；分段日志继续记录“cmhub 已返回 image_url / 下载完成 / 本地保存完成”的耗时。下载失败按当前任务失败记录，但不得重新调用 cmhub 生图接口导致重复扣点；`cover_done/generated_done` 必须等下载保存成功并写 DB 后才计数；停止逻辑继续取消未开始项，运行中请求/下载允许自然完成或失败。direct 兼容路径暂不改变。补 `tests/test_ai.py` 覆盖并发上限和下载线程池不阻塞后续生图提交、下载失败不重复扣点；补 `tests/test_gui.py` 覆盖开始日志显示实际并发 | DONE |
 | T-536 | GUI 按钮圆角全局统一 | T-512, T-513, T-523 | 现象：只有③「开始更新」及少数上色按钮（删除批次/删除账号/未匹配(n)）有 `border-radius: 4px`，其余按钮走原生渲染显直角——不一致。根因：圆角是 T-512/T-513 给按钮上色时顺带写进 QSS 的副产品，不是全局形状决策；一旦给 `QPushButton` 设 stylesheet 就放弃原生渲染，才补了 radius/border。方案（**方式 A：全局统一圆角**）：① 在 `app/gui/widgets.py` 抽一个**共享按钮基础样式常量/helper**（统一 `border-radius`，如 4px，与卡片 6px 圆角语言协调），并**接管按钮的全部视觉状态**——normal/hover/pressed/disabled/focus 的背景、边框都定义好，避免全局设 QSS 后按钮变扁平方块、丢 hover 反馈；② 在主窗口/app 级用全局 `QPushButton` QSS 应用该基础样式，让**所有按钮共享同一圆角**；③ warning（`startUpdateButton`）与 danger（`_danger_outline_button_style`：删除批次/删除账号/未匹配）按钮改为**只叠加颜色**，复用共享基础样式的圆角/内边距/状态，不再各自重写 radius/border——杜绝“上色=顺带圆角”的隐性耦合；④ 以 Windows 为主目标做一次视觉自测（hover/按下/禁用不劣于原生）。只改 GUI 样式层（`widgets.py` + 主窗口全局 QSS + 各上色按钮引用），不改任何按钮的启用/禁用逻辑、行为、业务流程、DB、Excel、Shopee/CDP。GUI 单测至少断言上色按钮仍带各自语义色且不再各自硬写 radius（改为引用共享样式）；圆角外观本身以人工视觉验收为准 | DONE |
+| T-546 | cmhub 客户端共享 Session + 连接池 + 代理处理（补 T-545 未覆盖的下载慢根因） | T-545, T-526 | 现象：实测生图拿到 `image_url` 后本地下载单条约 191 秒、而同一 URL 用 curl 约 10 秒；日志伴随 `connect_timeout: 连接 cmhub 超时`。T-545 已做「生图并发上限 5 + 独立下载线程池」解决“下载堵住生图槽位”的流水线问题，但**未根治单条下载在并发争抢下变慢**。根因（代码核实）：① cmhub 所有 HTTP（`_cmhub_call_once` 的生成/models/balance、`_download_cmhub_image` 的下载）都是**裸 `requests.get`/`requests.request`、无共享 `Session`**，每个任务全新 TCP+TLS，叠加同步生成长连接（单条 60~260s）与 `connect_timeout` 触发的重试，形成连接风暴/连接饥饿；② `requests` 默认 `trust_env=True` 读 `HTTP(S)_PROXY`/`ALL_PROXY`，若系统带慢代理会拖累，而干净窗口的 curl 直连快。方案：① cmhub 所有 HTTP 统一走一个**模块级共享 `requests.Session`**，挂 `HTTPAdapter(pool_connections/pool_maxsize)`，池大小 ≥（实际生图并发 + 下载并发）以免连接不足排队、复用连接减少握手与 connect_timeout；生成与下载共享该 Session（`requests.Session` 跨线程发请求安全，但连接池要够大）；② 代理处理——诊断日志脱敏记录 cmhub 请求是否经代理；对 cmhub 请求提供明确策略（可配 `trust_env=False` 或显式 `proxies`），避免误走慢代理，默认可先保持读环境但提供关闭开关；③ 复测口径——Session+连接池到位后单条下载耗时应回落到与 curl 同量级；若在 T-545 的并发上限 5 下仍显著慢，评估把 cmhub 生图默认并发再降（1~2）；④ 确认 connect_timeout 重试退避不加剧连接风暴。诊断建议：可先临时把图片并发设 1 复测以区分“并发争抢”与“代理”。边界：只改 `app/ai.py` 的 cmhub HTTP 客户端层（+ 可选 config 代理项）+ 诊断日志 + 相关文档；不改 cmhub 协议、T-545 的并发/下载池语义、生成编排、DB、Excel、CDP/Shopee。测试：`tests/test_ai.py` 覆盖共享 Session 被复用（mock 同一 session 多次调用）、代理配置被尊重、连接池大小设定；现有 cmhub 用例保持绿 | TODO |
 
 ## Phase 8 · 工程基础设施后续（`docs/engineering-review.md`）