refactor(web): simplify organize defaults and restore historical options

docs/runbook/dev.md

@@ -99,6 +99,10 @@ curl -H "Authorization: Bearer umt-dev-admin-key" "localhost:4390/api/v1/events?
 
 整理恢复区分两种情况：文件执行中断从原冻结计划和持久文件结果继续；作品或季集事实纠正后，通过 `retryOrganizeRecord` 从原业务请求重新规划。同一原记录的重规划串行，避免事件和巡检同时冻结重复计划。原请求保存一次性目标、操作方式和覆写，函数、任务身份与路径守卫不序列化，恢复时重新检查来源边界。已成功文件与资产保持原状，恢复主文件失败状态时也恢复其附属文件依赖。
 
+来源身份复用既有 `external_identity`，只持久化经过 TMDB 校验的辅助来源映射。Bangumi／豆瓣允许同一作品有多个分季身份，来源 ID 的全局唯一归属保持不变；需要单值 ID 的命名、刮削等消费者必须显式处理多值，不能随机取一条。身份解析不顺带改写资源季集，季集继续由所属模块换算。
+
+历史记录恢复仍走现有整理入口：从原请求、可信旧任务输入到冻结计划依次提取事实，区分可直接重试与需要补齐的预填。文件管理通过 `recoveryRecordId` 交给业务层恢复下载关联、洗版与未编辑覆写，表单只覆盖明确支持的本次选项；来源范围和隐含参数共同参与预览校验。前端共用恢复选项的纯转换，不另造恢复向导或第二套请求模型；默认开始整理和手动预览共用冻结计划与入队函数。
+
 季集计算和识别词归 sources-identity，整理请求、文件操作与入库状态归 acquisition-organize。整理把真实失败文件和同批正常文件样本交给映射事项，模拟与写入共用同一判断；映射重算后以 `media.episode_mapping_changed` 通知整理模块，只有季集已经确定的未完成记录重新规划。恢复预检与规划复用 `planFileEpisodes`，保留原资源的发布时间等解析上下文。Agent 的调查运行、预算和授权沿用现有机制，不另外创建恢复框架；身份补齐、重新排队和实际入库完成分别按业务事实核实。
 
 维护时先验证真实的成功、失败和恢复路径,尤其是授权、文件替换、取消与外部副作用；删除空壳或无使用者的机制时同步删除其专属测试与文档。不要为了目录对称增加转发层,也不要把不同阶段的状态合并成一个枚举。