feat(task): expose offline download file info

[gengjiawen]

Summary / 摘要

• Expose file_name and file_size in task API responses for offline download tasks.

• Persist and update offline download file metadata from supported providers.

• Initialize file name from the source URL when creating offline download tasks, including the SimpleHttp fallback path.

• This PR has breaking changes.
  / 此 PR 包含破坏性变更。

• This PR changes public API, config, storage format, or migration behavior.
  / 此 PR 修改了公开 API、配置、存储格式或迁移行为。

• This PR requires corresponding changes in related repositories.
  / 此 PR 需要关联仓库同步修改。

Related repository PRs / 关联仓库 PR:

• OpenList-Frontend: feat(task): show offline download file info OpenList-Frontend#547
• OpenList-Docs: N/A

Testing / 测试

• go test ./...
• go test ./internal/offline_download/... ./server/handles
• Manual test / 手动测试: not run; frontend display change is handled in the related frontend PR.

Checklist / 检查清单

• I have read CONTRIBUTING.
  / 我已阅读 CONTRIBUTING。
• I confirm this contribution follows the repository license, contribution policy, and code of conduct.
  / 我确认此贡献符合仓库许可证、贡献规范和行为准则。
• I have formatted the changed code with gofmt, go fmt, or prettier where applicable.
  / 我已按适用情况使用 gofmt、go fmt 或 prettier 格式化变更代码。
• I have requested review from relevant maintainers or code owners where applicable.
  / 我已在适用情况下请求相关维护者或代码所有者审查。

AI Disclosure / AI 使用声明

• This PR includes AI-assisted content.
  / 此 PR 包含 AI 辅助内容。

Tools used / 使用工具:

• ChatGPT
• Codex
• GitHub Copilot
• Claude
• Gemini
• Other (please specify) / 其他（请注明）:

Usage scope / 使用范围:

• Code generation / 代码生成

• Refactoring / 重构

• Documentation / 文档

• Tests / 测试

• Translation / 翻译

• Review assistance / 审查辅助

• I have reviewed and validated all AI-assisted content included in this PR.
  / 我已审核并验证此 PR 中的所有 AI 辅助内容。

• I have ensured that all AI-assisted commits include Co-Authored-By attribution.
  / 我已确保所有 AI 辅助提交都包含 Co-Authored-By 归属信息。

• I can reproduce all AI-assisted content included in this PR without any AI tools.
  / 我可以在没有任何 AI 工具的情况下重现此 PR 中包含的所有 AI 辅助内容。

[gengjiawen]

@j2rong4cn Can you take a look

[pikachuren]

🙏 感谢 @gengjiawen 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
⚠️ AI 分析结果仅供参考，可能存在误判或遗漏。如您发现任何问题或有不同意见，欢迎随时提出讨论和纠正。
⚠️ 重要提醒：即使 AI 评审认为代码质量良好且建议合并，最终是否合并仍需由项目维护者进行人工判定。项目维护者会综合考虑代码质量、项目规划、技术方向、团队资源等多方面因素做出决策。

🎯 结论

✅ 建议 Approve（由维护者人工确认）— 改动一致性好，顺带修复了 fmt.Errorf 的格式化漏洞

📖 概要

feat(task): expose offline download file info · 让离线下载任务能显示文件名与大小。
核心改动：tool.Status 新增 FileName / FileSize 字段，各 provider（115、115_open、123、aria2、pikpak、qbit 等）在 Status() 中填充。

🧭 整体方案

技术路线直白：在统一的 Status 结构上加两个字段，由各 provider 按自身 API 返回值填充。改动横跨多个 provider 但每处都很薄，且对不支持的 provider 留空即可，向后兼容良好，方案合理。

📊 变更统计

15 个文件（+121 / -12 行） | 功能 ⭐⭐⭐⭐⭐ | 最小改动 ⭐⭐⭐⭐ | 前向兼容 ⭐⭐⭐⭐⭐ | 方案设计 ⭐⭐⭐⭐

🚨 关键问题

P0（阻塞合并）：无

P1（建议修复）：无

P2（可选）：

• 💡 顺带把多处 fmt.Errorf(t.GetStatus()) 改成了 fmt.Errorf("%s", t.GetStatus())。这是个实打实的安全性修复——原写法把外部返回的字符串当作格式串，若其中含 %s / %! 等动词会产生错误输出甚至信息泄漏，go vet 也会告警。这个顺手修复很有价值，建议在 PR 描述里单独提一句~
• 💡 aria2.go 的 fileNameFromStatus 优先取 BitTorrent name、否则取第一个 selected 文件的 basename。对多文件种子只会显示第一个文件名，是否考虑在这种情况下显示种子名或文件数量呢？属于展示优化，不影响功能~
• 💡 123/client.go 的 offlineTaskFileName 优先用 UploadName 再退回 Name，逻辑正确。若其他 provider 也有类似双字段，可考虑统一到一个 helper~
• 💡 http/client.go 中 task.SetFileInfo(filename, fileSize) 被调用了两次（一次在 streamPut 判断前、一次在其内部）。功能上无害，但第一次调用时 fileSize 可能还是未修正的值，是否可以合并到一处？
• 💡 与 #2622 在 aria2.go / qbit.go / http/client.go 有重叠改动（都涉及 total > 0 判断），合并时会冲突，建议维护者留意顺序~

📂 逐文件分析

internal/offline_download/*/client.go（多 provider）

改动意图：填充文件名与大小。
代码逻辑：各 Status() 方法中为 s.FileName / s.FileSize 赋值，数据来源为各自 API 的任务对象。
问题分析：改动模式统一、无遗漏，未支持的字段留空不会影响原有展示。fmt.Errorf 的格式化修复是加分项。

internal/offline_download/aria2/aria2.go

问题分析：fileNameFromStatus 边界处理完整（跳过 Selected == "false" 与空 Path），仅多文件种子的展示可优化（P2）。

✅ 待处理清单

• [P2] 考虑多文件种子的文件名展示方式
• [P2] 合并 http/client.go 中重复的 SetFileInfo 调用
• [P2] 与 #2622 协调合并顺序（存在文件重叠）

🎯 结论：✅ 建议 Approve — 改动薄而一致，兼容性好，且顺带修复了格式化字符串漏洞。

[gengjiawen]

@jyxjjj PTAL

[jyxjjj]

fileNameFromURL may double-decode URL paths. url.Parse already decodes Path, so calling url.PathUnescape(name) again can turn a valid filename like a%2Fb into a/b, changing the actual destination filename in tryPutUrl.

Please avoid the second decode and add a test for double-encoded paths such as %252F.

[gengjiawen]

@jyxjjj Thanks for catching this! Fixed in 08db632: removed the second url.PathUnescape call in fileNameFromURL (since url.Parse already decodes Path), and added tests covering double-encoded paths — a%252Fb.txt now resolves to a%2Fb.txt instead of being double-decoded into a/b.txt.