feat(寄件): 支持管理员通过寄件码授权临时访客上传

[dawnStamp]

关联需求：#513
配套前端：vastsa/FileCodeBoxFronted#12

关闭游客上传后，管理员可发放有有效期和次数限制的寄件码。访客无需账号，复用原上传流程投递并取得普通取件码。

最终范围：只增加寄件授权

• 新寄件全部使用系统当前 file_storage、storage_path 和原 build_file_path、存储驱动。
• 删除寄件码的独立存储类型、目标目录、相关接口参数和筛选。接口拒绝客户端传入这些覆盖字段，不再单独配置账号、密钥、地址或存储规则。
• 文件大小、类型、分片、保存期限、总容量和限流继续由原系统设置及上传服务控制。
• 详情、下载、编辑、删除和过期清理复用原文件管理；只通过 FileCodes.delivery_id 关联寄件码。
• 普通上传的参数模型、分片规则、默认存储和公共驱动保持上游实现，不包含 2023 配置兼容、通用快照、通用分片修复或 Windows 检查修改。

寄件必需逻辑

• 口令、用途、授权期限、次数、启停及备注标签；不引入多用户体系。
• token 用途隔离、auth_version 撤销、刷新续期、会话归属校验与原子次数预占。
• 成功文件只存 FileCodes；预留复用 StorageReservation，移除影子文件表、独立上传接口和 HTML 后台。
• 耗尽停用并保留码，删除软删；列表 SQL 分页，口令按需读取且禁止缓存，已移除 HMAC 双存。
• 非分片寄件使用现有代理模式（含 S3）以核验真实大小，普通 S3 直传不变；旧寄件直传会话拒绝确认并安全回收。
• 配套原生界面只修改 2024，2023 源码不修改，旧寄件入口只提示切换主题。

升级与数据

• 013/014 保留历史收件关系和私有文件权限，缺少原口令的旧码停用，后台重设后再启用。
• 015 移除授权表的独立存储字段，保留 ID、计数和自增序列。
• 已上传文件和进行中的会话保留实际位置；不搬动旧文件。只有新上传跟随系统当前设置。

当前验证

• 原有后端测试：114 passed、2 skipped、13 subtests passed；PR 不包含新增或修改的测试代码。
• 临时内存数据库验证 015 幂等迁移、历史位置保留、拒绝自定义参数、新上传跟随系统、关闭游客上传仍能受控寄件，以及系统切换后旧文件可下载。
• 前端架构、类型检查和构建通过；浏览器确认没有自定义位置表单，寄件读取系统 3 MB 上限和原过期选项。
• 此前已做续期和存储协议验证；本轮未重复 17 分钟长传或真实云厂商联调，未部署生产服务。
• 已包含上游 2.7.0 / NAS 更新，只更新原两个 PR，不新建基础修复 PR。

既有演示截图

以下旧截图仅说明寄件流程；其中独立存储、目录配置和筛选已经移除，最终范围以上文为准。

寄件管理：筛选、标签与批量操作

创建寄件码：用途、有效期与次数

寄件码分享：口令、链接与二维码

访客凭码寄件：复用发送页面

文本寄件成功：生成独立取件码

[vercel]

Someone is attempting to deploy a commit to the vastsa's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vastsa]

先说结论：这个方向是对的，工作量也看得出来。

寄件码解决的就是 #513 那个真实痛点——公网关掉游客上传之后，临时访客还得能投递。PR 没有上账号体系，寄件 token 和 admin 隔离，次数用 SQL 原子预占，改码用 auth_version 作废旧凭证，文件还补了存储后端快照。这些点都踩在正经工程问题上，说明文档也写得很清楚，包括「没合 2.7、没做完整回归」这种限制，感谢。

配套前端：vastsa/FileCodeBoxFronted#12

不过按现状还不建议直接合，主要是架构叠了几层，后面上传/存储/清理会更难动。建议：

1. 先 rebase 当前 master（2.7 NAS）
   现在主干已经有 local_share 和本地 NAS 页。共同改动集中在 views.py、admin/services.py、路由和导航，硬合容易两边一起坏。

2. 2023 / 2024 选定一种产品语义，不要两套
   2024 Vue 复用 /share/*，会生成普通取件码；2023 兜底页走 /api/delivery/upload 且不传过期参数，结果是私有收件，访客拿不到取件码。多文件一边 ZIP 算 1 次，一边按文件计次。PR 描述里的「上传成功生成独立取件码」目前只对 2024 成立。issue 要的是丢到指定目录，需要先定一种，两套主题对齐。

3. 把寄件收薄，不要再搞第二套文件表和第三套上传
   apps.base 和 apps.delivery 已经互相依赖，upload_access / share_storage 把核心上传链路切开再缝。DeliveryFile 同时承担预占、会话、私有收件、分享关联和清理队列，真正分享还在 FileCodes，容量还要两边加。更干净的做法：DeliveryCode + FileCodes.delivery_id，上传鉴权做一层薄 Depends。
   /api/delivery/upload 这条独立上传、以及 apps/delivery/static/* 整套 HTML 管理页建议砍掉。2023 主题提示「请换 2024」即可，不必维护两套能力不一致的后台（兜底页没有批量/标签/改码/二维码，session key 也不一样）。

4. 寄件码用尽不要物理删除
   删掉之后 delivery_id 变孤儿，「按码看收件」直接 404。deleted 字段也还留着，半截软删。保留码、停用即可。

5. 补几处落地问题

   • 寄件 JWT 15 分钟且前端不续期，大文件分片会中途 401
   • list_codes 全表拉进 Python 再筛，口令原文每次都带出来，改成 SQL 分页
   • 口令 HMAC + 明文双存意义不大；能再复制可以，但列表当凭证数据保护
   • owner_id="admin" 先别铺进每条 SQL，真要接多用户再加归属
   • 上传鉴权、配额、关闭游客上传，这几条路径需要测试；现在几乎没有新测试
   • 存储快照、2023 配置字段兼容、分片大小校验，建议拆开单独合
   • 兜底 OneDrive 临时目录还留着 fr- 前缀

可以留的：token 隔离、次数预占、auth_version、存储快照、路径校验、CSP、校验接口限流、前端 publicApiClient / createDeliveryUploadClient 不和管理员会话搅在一起。这些都值得保留。

功能方向能合，这版先瘦身、对齐语义、跟上 2.7 再看。

[dawnStamp]

先说结论：这个方向是对的，工作量也看得出来。

寄件码解决的就是 #513 那个真实痛点——公网关掉游客上传之后，临时访客还得能投递。PR 没有上账号体系，寄件 token 和 admin 隔离，次数用 SQL 原子预占，改码用 auth_version 作废旧凭证，文件还补了存储后端快照。这些点都踩在正经工程问题上，说明文档也写得很清楚，包括「没合 2.7、没做完整回归」这种限制，感谢。

配套前端：vastsa/FileCodeBoxFronted#12

不过按现状还不建议直接合，主要是架构叠了几层，后面上传/存储/清理会更难动。建议：

1. 先 rebase 当前 master（2.7 NAS）
   现在主干已经有 local_share 和本地 NAS 页。共同改动集中在 views.py、admin/services.py、路由和导航，硬合容易两边一起坏。

2. 2023 / 2024 选定一种产品语义，不要两套
   2024 Vue 复用 /share/*，会生成普通取件码；2023 兜底页走 /api/delivery/upload 且不传过期参数，结果是私有收件，访客拿不到取件码。多文件一边 ZIP 算 1 次，一边按文件计次。PR 描述里的「上传成功生成独立取件码」目前只对 2024 成立。issue 要的是丢到指定目录，需要先定一种，两套主题对齐。

3. 把寄件收薄，不要再搞第二套文件表和第三套上传
   apps.base 和 apps.delivery 已经互相依赖，upload_access / share_storage 把核心上传链路切开再缝。DeliveryFile 同时承担预占、会话、私有收件、分享关联和清理队列，真正分享还在 FileCodes，容量还要两边加。更干净的做法：DeliveryCode + FileCodes.delivery_id，上传鉴权做一层薄 Depends。
   /api/delivery/upload 这条独立上传、以及 apps/delivery/static/* 整套 HTML 管理页建议砍掉。2023 主题提示「请换 2024」即可，不必维护两套能力不一致的后台（兜底页没有批量/标签/改码/二维码，session key 也不一样）。

4. 寄件码用尽不要物理删除
   删掉之后 delivery_id 变孤儿，「按码看收件」直接 404。deleted 字段也还留着，半截软删。保留码、停用即可。

5. 补几处落地问题

   • 寄件 JWT 15 分钟且前端不续期，大文件分片会中途 401
   • list_codes 全表拉进 Python 再筛，口令原文每次都带出来，改成 SQL 分页
   • 口令 HMAC + 明文双存意义不大；能再复制可以，但列表当凭证数据保护
   • owner_id="admin" 先别铺进每条 SQL，真要接多用户再加归属
   • 上传鉴权、配额、关闭游客上传，这几条路径需要测试；现在几乎没有新测试
   • 存储快照、2023 配置字段兼容、分片大小校验，建议拆开单独合
   • 兜底 OneDrive 临时目录还留着 fr- 前缀

可以留的：token 隔离、次数预占、auth_version、存储快照、路径校验、CSP、校验接口限流、前端 publicApiClient / createDeliveryUploadClient 不和管理员会话搅在一起。这些都值得保留。

功能方向能合，这版先瘦身、对齐语义、跟上 2.7 再看。

好的，我去优化上传一下，确实有些考虑的不周全。