refactor(config): 解装模式取值语义化为 拆解全部/拆解舰种/保留舰种

[wufeng5702]

背景

• 中文取值 黑名单/白名单 与仓库自身约定方向相反（bath_repair_blacklist 黑名单=不修，此处=要拆）
• disable/include/exclude 语义含糊，表达不出「列表的用途」

改动

• 枚举成员 disable/include/exclude → all/destroy_only/keep_only，中文取值改为 拆解全部 / 拆解舰种 / 保留舰种
• 旧成员名保留为枚举别名；配置字段名 destroy_ship_work_mode 与类名 DestroyShipWorkMode 保持原样，仅使用旧键格式
• 同步日志措辞、YAML 模板、文档与测试

兼容性

• 旧值 不启用/黑名单/白名单、disable/include/exclude、数字 0/1/2 运行期仍兼容，解装行为零变化，老用户无需改配置

测试

• pytest -q：1281 passed（2 个既有失败在干净 main 上同样复现，与本改动无关）
• pre-commit（ruff / codespell 等）通过

[github-actions]

Review from [gpt-4o-mini]:
- Total changes: 12
- Filtered: 12
- Reviewed: 12
- Found issues: 0

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[github-actions]

Review from [deepseek-v4-flash]:
- Total changes: 12
- Filtered: 12
- Reviewed: 12
- Found issues: 7

[github-actions]

该改动整体思路清晰，将原先含义模糊的 disable/include/exclude 重命名为更明确的 all/destroy_only/keep_only，并保留了旧成员名作为别名，基本保持了赋值层面的向后兼容。

但存在一个潜在的兼容性问题需要关注：

1. 枚举别名的 name 属性会发生变化
   Python 中，当多个枚举成员指向同一个值时，后定义的成员会成为先定义成员的“别名”。访问别名成员时，其 .name 返回的是规范成员（第一个定义者）的名字，而不是别名本身的名字。
   例如：

   DestroyShipWorkMode.disable.name   # 现在是 'all'
   DestroyShipWorkMode.include.name   # 现在是 'destroy_only'
   DestroyShipWorkMode.exclude.name   # 现在是 'keep_only'

   而旧代码中这些 .name 分别是 'disable'、'include'、'exclude'。如果项目中有任何代码依赖枚举成员的 .name 做序列化、日志输出、用户展示或持久化，都会在升级后发生行为变化，可能导致数据不一致或显示错误。

2. 枚举遍历结果会丢失旧成员名
   使用 list(DestroyShipWorkMode) 或类似遍历时，只会得到 all、destroy_only、keep_only，而 disable、include、exclude 不会出现。如果外部代码曾依赖遍历结果中的旧名称，也会受影响。

如果该枚举仅以整数值形式参与配置和逻辑判断，那么本次改动没有问题；但若库的 API 承诺或外部用户可能使用 .name，建议在变更说明中明确指出，或在语义上进行更彻底的兼容处理（例如使用 enum.Enum 的自定义属性或完整保留旧成员为独立枚举值，不过那样就无法同时保持数值映射）。否则，应说明为破坏性变更并规划迁移。

[github-actions]

该变更存在潜在兼容性问题，需要确认：

1. 配置值变更可能破坏现有逻辑：如果代码其他部分仍按旧值 不启用 / 黑名单 / 白名单 进行匹配，而配置文件中已改为 拆解全部 / 拆解舰种 / 保留舰种，会导致配置解析失败或行为异常。需同步检查并更新所有读取该配置项的代码、文档及示例配置。

2. 语义转换是否完全等价：旧模式 不启用 注释为“解装所有舰船”，这在语义上容易误解；新模式 拆解全部 更直观。但需确认“黑名单/白名单”与“拆解舰种/保留舰种”在逻辑上一一对应，且不存在取反或边界差异。

3. “快速拆解”行为是否明确：新注释新增“走快速拆解”这一描述，但旧实现中“解装所有舰船”是否一定走快速拆解？若该字段还影响其他流程，需确认改动后行为符合预期，避免产生性能或功能差异。

建议：仔细核对代码中对 destroy_ship_work_mode 的所有引用，确保字符串常量已同步更新，并补充/更新对应测试用例。

[github-actions]

以下是针对该代码变更片段的审核意见：

1. 旧值别名测试覆盖不足
   test_destroy_ship_legacy_value_alias 的 docstring 声称“不启用/黑名单/白名单、disable/include/exclude 仍可用”，但实际只测试了 白名单 → keep_only 一个用例。建议使用参数化方式覆盖所有声明的旧值别名，避免后续重构时遗漏或破坏其他别名。

2. 缺少对旧枚举值 include / exclude 的兼容性验证
   原测试断言由 include 改为 destroy_only，这可能是迁移后的预期变化，但新测试并没有显式验证旧值 include / exclude 是否仍然兼容。如果已有用户配置中使用了这些旧值，直接移除会导致兼容性回归。建议补充对旧枚举值的解析测试，确认它们是被继续支持还是会被明确拒绝。

3. 测试文件名在参数化中重复使用
   test_destroy_ship_chinese_alias 多次传入相同的 destroy_alias.yaml，如果 tmp_yaml fixture 不是每次调用都生成独立临时目录，则可能存在文件覆盖或串扰问题。建议确认 fixture 作用域，或使用不同文件名以避免潜在冲突。

4. 可维护性优化
   多个测试中重复构造 YAML 内容，可以考虑抽取出公共的 fixture 或辅助函数，减少重复代码，便于后续修改测试基础配置时保持一致。

5. 暂无安全性或性能问题
   变更中未发现硬编码敏感信息、执行外部代码等风险；测试代码逻辑简单，也无可观察到的性能问题。