[Bug]: 跨天续传导致文件合并失败，且中断上传后分片文件未被清理

[tada-zako]

Describe the bug

• 跨天断点续传失败： 当用户分片上传一个大文件并中途暂停后，如果第二天（或更长时间后）尝试恢复上传，文件断点续传功能会失败。虽然续传本身表面上成功，但最终文件合并时会提示文件不完整或分片缺失。
• 冗余分片文件未清理： 如果文件上传中断或失败，已上传的分片文件会一直保留在系统中，未被自动清理，可能导致存储空间浪费。
• 此外，get_chunk_file_path_name （位于 apps\base\utils.py）缺少像是 get_file_path_name 函数中对于文件路径的合规性检查，没有调用 sanitize_filename 函数进行文件路径的处理。

To Reproduce
很抱歉，由于我目前并不具备通过编写 pytest 测试实例，或进行长时间的实际运行测试的能力，来严格验证这些问题，但我根据对代码的逻辑分析，推测出如下复现步骤：

1. 在第一天通过分片方式上传一个大文件，在未完全上传完成时，中断上传操作。
2. 等到第二天重新打开项目上传界面，尝试恢复上传之前未完成的文件。
3. 预测结果会是可以成功续传，但是最终合并文件时，会触发文件无法找到的错误。

Additional context

• 隔天续传问题分析：
  • 核心问题在于 get_chunk_file_path_name 函数（位于 apps\base\utils.py）在生成分片存储路径时，依赖当前日期。
  • 当隔天续传时可能会导致如下文件路径产生：

# 昨天上传分片1-4：
share/data/2025/06/11/upload_123/chunks/0.part
share/data/2025/06/11/upload_123/chunks/1.part
share/data/2025/06/11/upload_123/chunks/2.part
share/data/2025/06/11/upload_123/chunks/3.part

# 今天上传分片5-6：
share/data/2025/06/12/upload_123/chunks/4.part  # 不同路径
share/data/2025/06/12/upload_123/chunks/5.part

• 而在调用 api 接口时，续传不会检测出日期变化的问题。而合并分片时，merge_chunks 函数（位于 core\storage.py）中的 save_path 参数也是基于当天时间生成的，导致最终在进行合并分片时，无法查找到昨天上传的分片，从而触发错误。
• 分片文件清理问题：很抱歉，由于本人实力不济，无法确定是否该项目确实没有对于残留的、未完成完整上传的文件分片进行处理的逻辑。但是，我确实只注意到 clean_chunks 逻辑只有一次调用（位于 apps\base\views.py）。

非常抱歉，我目前没有充足的时间进行实际的代码运行测试，也没有编写 pytest 案例的能力（太杂鱼了，真不会写）来验证上述结论。我的分析主要基于对代码逻辑的阅读和推断。希望能得到维护者的确认，以判断这是否确实是需要修复的 Bug。

[vastsa]

感谢反馈

[vastsa]

Hello! To better manage the project roadmap, I have used Gemini to analyze and consolidate all pending issues. This specific topic has been recorded in the new Master Tracking Issue (see #434). I am closing this ticket to keep the issue tracker clean, but please rest assured your feedback is on the to-do list. Let's continue the discussion there!

你好！为了更好地管理项目进度，我使用 Gemini 对现有 Issue 进行了全面的梳理和汇总。该问题/建议已被收录至新的 汇总 Issue (请见 #434) 中。为了避免重复和方便管理，我将关闭此工单，请移步至汇总贴关注后续进展。非常感谢你的反馈！