feat(engines): Kohya 引擎化——可插拔 / 可卸载（云盘 30G 与 Krea2-only）

[wochenlong]

背景

云端常见 系统盘仅 30G。当前三套训练运行时各自带 Torch/CUDA，无法共用 site-packages：

块	约占用
Kohya（主 runtime / conda env）	~8G
Anima Fast（独立 venv，cu130）	~7G
Musubi（独立 venv）	再 ~5–7G
再加 conda base / IDE / 输出 / 解压临时	很容易顶满 30G

只训 Krea2（Musubi）的用户并不需要 Kohya，但今天 Kohya 仍是「内置 · 永远占盘」的承重墙，等于强制交税。

已有缓解：Kohya-only / Musubi-only 分轨整合包（打包侧）。本 Issue 讨论的是产品架构下一阶段——Kohya 也做成可插拔、可卸载的引擎，与 Fast / Musubi 同一套管理面。

相关设计：docs/design/training-engine-management.md、docs/design/portable-2026.md（engines/ 层）。

目标

1. Kohya 从 builtin 演进为与 Musubi / Fast 同级的 optional 引擎（可安装 / 卸载 / 就绪探测）。
2. Musubi-only（或不装 Kohya）时：GUI 壳仍可启动，能训 Krea2；Kohya 相关训练入口灰掉并提示安装。
3. 卸载 Kohya 后系统盘可回收约 ~8G 量级（视环境而定）。
4. 云部署文档写清：单引擎 30G 勉强；双引擎建议 40G+ 或引擎放数据盘。

非目标（本 Issue 不一次做完）

• 强行合并三套 Torch 到同一 site-packages（依赖冲突，不可行）。
• 把 Anima Fast 设成全局默认。
• 立刻废弃分轨包（分轨包仍是短期正解）。

建议分期

阶段	内容	验收
A. 口径 + 文档	引擎管理 UI/文档：Kohya 标明体积与「可后续卸载」；云盘建议；推荐分轨包	用户知道为何 30G 塞不下三引擎
B. 管理面对齐	设置 → 训练引擎：Kohya 卡片与 Fast/Musubi 同态（状态机、ENGINE_NOT_READY）	未装/已卸时训练页行为正确
C. runtime 拆分	GUI 壳瘦身；Kohya 迁入 engines/kohya/ 独立 venv；install/uninstall API	Musubi-only 实例不装 Kohya 仍可训 Krea2，磁盘少一截

风险

• 今日大量 schema / 训练页 / 主 Python 与 Kohya 绑定，直接「卸载」会弄挂 WebUI——C 阶段前对外勿宣称可卸载。
• 打标等工具是否依赖主 env，需要一并梳理依赖边界。

协作

@IryNeko 请看一下方向与排期（尤其前端工作台 / 引擎管理 UI，以及「冷启动默认是否随包类型变」：Musubi 包默认引擎 = Musubi，不再强行默认 Kohya）。

[wochenlong]

关联后期项（P3）：图像编辑训练 / Kontext 等见 #252（训练 UI 填路径即可，Dataset 配对 UI 后置）。