feat(寄件): 为 2024 版界面新增凭码上传与寄件管理

[dawnStamp]

关联需求：vastsa/FileCodeBox#513
配套后端：vastsa/FileCodeBox#534

仅为 2024 主题新增寄件码授权入口和后台管理。访客验证后复用原发送页面，上传成功返回普通取件码。

配置与文件管理全部复用

• 删除寄件独立存储类型、目标目录、自定义位置开关，以及对应列表筛选和数据字段。
• 寄件与普通发送直接读取同一个 configStore；文件大小、类型、分片开关和文件过期策略均由原系统设置控制，不再由寄件会话覆盖配置。
• 文件详情、下载、编辑、删除复用 FileManageView 和原文件服务，只增加 delivery_id 范围过滤及历史私有文件保护。
• 标签解析直接共用原文件管理实现，不维护另一套规则。
• 寄件码只管理口令、用途、授权有效期、次数、启停和备注标签。授权有效期不替代文件保存期限。

保留的寄件能力

• 访客 token 与管理员会话隔离；支持到期前及请求前续期。
• 多文件 ZIP、文本、分片和代理上传均复用现有流程；非分片寄件依后端使用代理模式，普通 S3 直传不变。
• 管理页按列表、表单、批量、分享拆分；口令按需读取。
• 保留最小公共页脚入口和 2024 功能标记；不修改 2023 主题源码。
• 自动复制不阻塞上传完成状态（同样影响普通发送的完成交互）。
• 恢复公共页脚“凭码寄件”的收件箱图标；修正寄件管理 scoped 表格样式、表头与内容边距、搜索框及按钮高度、复选框留白和窄屏分页。

验证与限制

• 本次前端发布构建已通过架构检查、TypeScript 检查和 Vite 生产构建；最新样式提交为 e69944e。
• 已部署至现有实例，健康检查正常，并核对线上图标资源、表格 scoped 选择器和搜索栏对齐类名。
• 本次未做浏览器视觉回归，不能以资源核对代替实际页面验收；未新增或运行测试用例。
• 此前已在浏览器确认寄件表单没有独立存储/目录配置，创建后使用系统上传上限及原过期选项。
• 本次提交仅包含 4 个界面文件；整个 PR 相对上游不包含新增或修改的测试代码。
• 已包含上游 NAS 页面和导航；配套后端见上方 #534 链接。

既有演示截图

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

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

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

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

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

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

[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]

可以贴一下截图哦

[dawnStamp]

可以贴一下截图哦

提交里已有截图，改动已兼容现有功能 ui。

[vastsa]

先说结论：这个方向是对的，前端这侧也做得很认真，感谢。

凭码寄件复用现有发送页，而不是再做一套上传；publicApiClient / createDeliveryUploadClient 和 admin token 分开，寄件 401 不会清掉管理员会话。管理页复用文件列表看收件，创建后给口令/链接/二维码，这些都贴合 2024 的现有结构。说明里把「只改 2024、依赖配套后端、没做完整回归」写清楚了，也很好。

配套后端：vastsa/FileCodeBox#534

和后端一起看，按现状还不建议直接合，建议对齐这几件事：

1. 先和当前 main 的 NAS 分享页对一下路由、后台导航、公共文件服务
   分支还没合上游本地 NAS 页，合并前这块会撞。

2. 和后端统一产品语义
   这边走普通发送，成功后给取件码；后端 2023 兜底页是私有收件、访客拿不到取件码。多文件这边 ZIP 算 1 次。前后端、两套主题需要先定一种行为。

3. 管理页拆一下
   DeliveryManageView.vue 八百多行、useDeliveryAdmin.ts 五百行，筛选/批量/编辑/分享挤在一块，后续难改。按列表、创建/编辑、批量操作拆开更合适。

4. 寄件 token 要能续期
   后端 JWT 15 分钟，大文件分片超时会 401，这边目前没有 refresh。

5. 别把 delivery session 直接 spread 进 config
   useSendFlow 里 ...getDeliverySession() 会把 token、remaining 等混进配置对象，后续很容易踩。覆盖 upload_size / expire_style 等白名单字段就行。

后端那侧还有：影子表 DeliveryFile、第二条上传 /api/delivery/upload、后端 HTML 管理页、用尽物理删码、全表内存筛选。前端可以继续复用发送页和管理布局，不必再为 2023 补一套原生界面。

方向保留，这版跟后端一起瘦身、对齐 2.7 再看。

[dawnStamp]

先说结论：这个方向是对的，前端这侧也做得很认真，感谢。

凭码寄件复用现有发送页，而不是再做一套上传；publicApiClient / createDeliveryUploadClient 和 admin token 分开，寄件 401 不会清掉管理员会话。管理页复用文件列表看收件，创建后给口令/链接/二维码，这些都贴合 2024 的现有结构。说明里把「只改 2024、依赖配套后端、没做完整回归」写清楚了，也很好。

配套后端：vastsa/FileCodeBox#534

和后端一起看，按现状还不建议直接合，建议对齐这几件事：

1. 先和当前 main 的 NAS 分享页对一下路由、后台导航、公共文件服务
   分支还没合上游本地 NAS 页，合并前这块会撞。
2. 和后端统一产品语义
   这边走普通发送，成功后给取件码；后端 2023 兜底页是私有收件、访客拿不到取件码。多文件这边 ZIP 算 1 次。前后端、两套主题需要先定一种行为。
3. 管理页拆一下
   DeliveryManageView.vue 八百多行、useDeliveryAdmin.ts 五百行，筛选/批量/编辑/分享挤在一块，后续难改。按列表、创建/编辑、批量操作拆开更合适。
4. 寄件 token 要能续期
   后端 JWT 15 分钟，大文件分片超时会 401，这边目前没有 refresh。
5. 别把 delivery session 直接 spread 进 config
   useSendFlow 里 ...getDeliverySession() 会把 token、remaining 等混进配置对象，后续很容易踩。覆盖 upload_size / expire_style 等白名单字段就行。

后端那侧还有：影子表 DeliveryFile、第二条上传 /api/delivery/upload、后端 HTML 管理页、用尽物理删码、全表内存筛选。前端可以继续复用发送页和管理布局，不必再为 2023 补一套原生界面。

方向保留，这版跟后端一起瘦身、对齐 2.7 再看。

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