feat(chunk upload): Support uploading by chunks on drivers/local

[thetapilla]

Issue

Partial implementation to #5480

Summary

灵感来自cloudflare的上传文件大小限制导致报413。
本PR为仅适配本地存储的分块上传实现，补齐从用户到服务器端接收的上传链路，并兼容原上传协议：

1. 新增上传策略与分块会话协议（policy/init/chunk/complete/cancel），支持前端按策略自动切换上传方式。
2. 新增 Local 存储的分块配置项 upload_chunk_size_mb（范围 0-4096，0 表示关闭分块上传）。
3. 新增会话失败清理与后台回收机制，降低上传中断后临时分块残留风险。
4. 前端上传流程接入策略驱动分块上传，并在存储配置页增加 Local 分块参数展示与保存前严格校验。

说明：本PR描述覆盖前后端整体方案；前端代码通过 companion PR 提交。

• alist-web companion PR:
  feat(chunk upload): Support uploading by chunks on drivers/local alist-web#295

Changes

后端（alist）

1. Local 存储配置项与参数校验

   • drivers/local/meta.go: 增加 upload_chunk_size_mb 配置元信息。
   • drivers/local/driver.go: 在 Init 中增加 0-4096 范围校验。

2. 分块上传核心生命周期

   • internal/fs/chunk_upload.go:
     • 新增策略解析：GetUploadPolicy（当前按 Local 存储配置返回分块策略）。
     • 新增会话流程：InitChunkUpload、AppendChunk、CompleteChunkUpload、CancelChunkUpload。
     • 新增失败清理：会话失败、分片顺序错误、complete 异常等路径触发清理。
     • 新增后台回收：StartChunkUploadReaper 定时清理过期会话与临时分块文件。

3. API 与路由接线

   • server/handles/fsup_chunk.go: 新增 5 个 handler。
   • server/router.go: 新增 /api/fs/upload/policy|init|chunk|complete|cancel 路由。
   • cmd/server.go: 启动时挂接 fs.StartChunkUploadReaper()。

前端（alist-web，companion PR）

1. 上传流程接入

   • src/pages/home/uploads/chunk.ts: 新增策略驱动分块上传器，失败时 best-effort cancel。
   • src/pages/home/uploads/Upload.tsx: 接入 uploadWithChunkPolicy(..., fallbackUploader)。

2. Local 配置项展示与校验

   • src/pages/manage/storages/Item.tsx: 增加 upload_chunk_size_mb 字段输入约束与提示。
   • src/pages/manage/storages/AddOrEdit.tsx: 保存前校验，拒绝非整数或超出 0-4096 的值。
   • src/lang/en/drivers.json、src/lang/en/storages.json: 增补文案与错误提示。

当前边界

1. 本PR的实现会在服务器端完成文件完整性校验后才把数据流开放给driver，因而目前设计成只对本地存储生效。
2. 不包含跨服务重启的断点续传恢复语义（本次侧重上传分块与失败清理闭环善后）。

Testing

自动化测试

已运行（开发过程中多次执行，均为 exit code 0）：

go test ./cmd ./drivers/local ./internal/fs ./server ./server/handles
go test ./internal/fs ./drivers/local
go test ./drivers/local ./internal/fs

联调与行为验证

1. 后端服务与前端开发环境联调通过（/ping、/api/public/settings 可访问）。
2. 上传链路行为验证：
   • 策略命中时走分块上传流程。
   • 浏览器 Network 调试页可见多个 chunk 请求。
   • 文件小于配置的分块大小时自动fallback到原上传策略。
   • 失败路径触发 cancel/cleanup 逻辑。
3. Local 配置边界验证：
   • upload_chunk_size_mb 在保存时拒绝负数与大于 4096 的值。
   • 合法边界值 0 与 4096 可保存。

PR #9457 关联性

重合度评估

1. 代码重合低：
   • 本PR侧重上传协议层分块（API 会话、分片传输、清理）。
   • PR9457 侧重驱动层分块（Chunker存储驱动与分片落盘组织）。

兼容性判断

1. 直接合并冲突风险低。
2. 当前策略硬编码绑定Local，其他driver不会自动走本PR上传分块协议。

Improvements

在想怎么能往边收块边喂给driver流这方面去靠，比如给driver一个PipeReader什么的，还在想。。
那时候说不定就能打通其他的driver了

[okatu-loli]

感谢这个 PR，整体实现比较完整，尤其是上传会话生命周期（init/chunk/complete/cancel）、失败清理和后台回收这块考虑得比较周全 👍

不过目前仓库里已经有一个相关方向的实现：PR #9457，它是在 driver 层引入 chunker 能力，目标是把“分片能力”做成通用存储抽象。

对比下来，这个 PR（PR #9472）主要是在 上传协议 / API 层实现分块上传，并且当前逻辑是绑定 Local 存储，没有抽象到 driver capability。

从长期架构上看，我们更倾向于：

• 由 driver 提供“是否支持分片 / 如何落盘”的能力
• 上传层根据 driver capability 决定是否启用 chunk upload，而不是针对某个具体存储（如 Local）做特化逻辑

换句话说，这个 PR 中的上传链路（策略协商、会话管理、清理机制等）是有价值的，但更适合建立在 chunker driver 之上，而不是单独形成一套 Local-only 的实现。

因此这边的建议是：

1. 先将该 PR 标为 draft，避免与 feat(driver): add chunker support #9457 形成两条并行方案
2. 后续如果 feat(driver): add chunker support #9457 合入，可以考虑基于其能力对这里的上传协议进行重构（policy / session / cleanup 等部分是可以复用的）

如果你这边有意愿继续推进这一方向，也很欢迎一起把 driver 与上传链路这两层整合成一个更通用的方案。