[BUG] 189CloudPC 普通上传路径命中天翼服务端 MD5 去重后，重新上传的图片不触发缩略图生成（官方客户端同操作可以恢复） #3320

请确认以下事项

• 我已确认阅读并同意 AGPL-3.0 第15条 。 本程序不提供任何明示或暗示的担保，使用风险由您自行承担。
• 我已确认阅读并同意 AGPL-3.0 第16条 。 无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。
• 我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。
• 我已确认阅读了OpenList文档。
• 我已确认没有重复的问题或讨论。
• 我已确认是OpenList的问题，而不是其他原因（例如 网络 ，依赖或操作）。
• 我认为此问题必须由OpenList处理，而非第三方。
• 我已确认这个问题在最新版本中没有被修复。
• 我没有阅读这个清单，只是闭眼选中了所有的复选框，请关闭这个 Issue 。

OpenList 版本（必填）

v4-main-20261010 (Commit: 482464c)

使用的存储驱动（必填）

189CloudPC（个人云）

问题描述（必填）

继 #3081（已由 #3083 修复家庭云转存临时文件名丢失扩展名的问题）之后，在为约 13 万张历史缺缩略图图片做批量修复的过程中，发现普通上传路径存在一个关联但独立的问题。

历史背景：这批图片由旧版家庭云转存进入个人云，当时驱动使用 0<UUID>.transfer 临时名上传，天翼服务端未识别为图片，因此从未生成缩略图。#3083 修复了新上传的命名问题，但已存在的存量文件仍缺缩略图，需要"重新上传"来触发天翼的媒体处理管线。

通过 OpenList 普通上传路径（family_transfer=false，rapid_upload=false）将个人云中已存在的文件下载后重新上传，即使完整走 stream 上传，天翼服务端在 initMultiUpload 阶段命中同 MD5 数据对象（FileDataExists=1），跳过真实数据落盘，直接 commit 建立目录项。结果：缩略图不会生成。

对照实验（同一账号、同一文件）：

官方客户端在服务端同样存在去重的情况下仍能触发缩略图生成，推测其上传接口携带了额外的场景参数（如 opScene，drivers/189pc/utils.go 中恰有一行被注释的 extend: {\"opScene\":\"1\",...} 参数暗示该接口存在场景区分），使服务端在 commit 时重新触发媒体处理管线。

复现步骤：

1. 挂载 189CloudPC 个人云（family_transfer=false，rapid_upload=false，upload_method=stream）
2. 找一张个人云中已存在、无缩略图的图片
3. 通过 OpenList 下载到本地，再通过 OpenList 上传回同一账号任意目录
4. 观察上传：流量远小于文件大小（服务端去重命中）
5. 等待后检查：thumb 字段始终为空

对照：用天翼官方客户端做同样的下载-上传，缩略图正常生成。

期望：普通上传路径提供绕过服务端 MD5 去重的手段，或复刻官方客户端的上传场景参数，使重新上传能触发缩略图生成——否则存量缺缩略图文件（#3081 时代遗留的）只能通过反复开关家庭云转存来修复，门槛高且慢。

日志（必填）

日志无显式错误：上传 HTTP 200，commit 成功，仅 thumb 恒为空。（关键现象是响应体中 FileDataExists=1 导致零字节传输，而非报错）

配置文件内容（必填）

{
  "driver": "189CloudPC",
  "type": "personal",
  "family_transfer": false,
  "rapid_upload": false,
  "upload_method": "stream"
}

AI生成内容

• 我使用了AI工具生成此内容
• 我没有使用AI工具生成此内容

AI模型是

GPT