feat(file): 优化文件上传处理和ID管理规范

- 新增 buildFileProxyUrl 函数构建永久代理路径，避免富文本图片链接过期
- 重构 uploadFile 函数，统一将后端返回的数值型 ID 转换为字符串
- 在业务富文本编辑器中使用永久代理路径替换临时签名 URL
- 完善 API 适配层 ID 规范，确保所有 ID 字段统一转换为字符串类型
- 移除废弃的编辑器相关路由和组件
- 更新构建代理配置以支持富文本图片直连访问
- 删除冗余的类型定义和依赖包

AGENTS.md

@@ -262,6 +262,7 @@ const directionLabels = getLabels(row.directionCodes, { separator: '，' });
 - 如果后端当前接口暂时还返回数值型 ID，前端也必须尽可能在 `typings`、API 适配层或进入业务层前转成 `string`，不要把 ID 按 `number` 扩散到页面、store 和组件里。
 - 但要注意：如果后端把超出 JS 安全整数范围的 Long 直接作为 JSON 数字返回，前端在业务层再 `String(number)` 只能得到“已经丢精度后的错误字符串”。这种情况必须明确记为接口契约风险，不要误判为“前端已安全处理”。
 - 因此，新增或改造接口时，最稳妥的契约仍然是：后端长整型 ID 直接按字符串返回；前端全链路按字符串接收和传递。若后端暂未改，前端侧也不得新增 `number` 口径 ID 用法。
+- API 适配层兜底（实操约束）：所有从后端接收的数值型 ID 字段（不论后端实际返回 `string`、`number` 或两者混合），都必须在 `src/service/api/*` 的 normalize 或 map 函数中显式调用 `String(rawId)` 归一一次；前端业务层（`views`、`store`、组件、`Map` 键、路由参数）只接收 `string` 形态，永远不需要自己 `String()`。这条与后端是否做了 Long → String 全局序列化无关——后端做了是双保险，没做且字段取值始终在 JS 安全整数内（例如 `infra_file_config.id` 永远是两位数）也是合理选择，前端 normalize 已经把口径收死，业务层无感。但这条不开按字段取值范围豁免的口子：前端 normalize 是无差别的，任何 ID 都要 `String()`，不要按某个字段当前取值大小决定要不要走 normalize，避免后续逐步污染仓库的 ID 纪律。
 - 对仓库中的历史代码，原则是“不再新增 number 口径 ID，当前任务触达相关链路时优先顺手矫正”；不要继续复制历史写法。
 - 遵循仓库现有的 Vue SFC 风格：`script setup`、类型化 store、职责单一的小型 composable/helper。
 - 修改界面时优先延续 `src/layouts` 和 `src/theme` 中已有的 UI 模式，不要平行引入另一套设计体系。