fix(upload,models): 上传落盘补齐兜底 + 不可用模型归因准确（v0.7.5）

两个真实缺陷，都由本轮的「跨端边界验收」暴露：

一、上传落盘：去重命中时删掉了唯一副本（T-WEB-017）
persistTempFile（动作 / 模型 / 场景上传走的通路）在 sha256 去重命中时直接
safeUnlink(tempPath) 并返回旧记录 —— 一旦记录指向的路径不存在（换过 STORAGE_DIR、
只恢复数据库、手工删过文件），上传仍返回 201，但后续动作预处理 500
（实测 ENOENT .../<sha>.vmd）、模型分析与缩略图静默失败。持久化通路 persistBuffer
早在上一轮就补了「文件缺失则按原路径补写」，这条通路漏了；现在同样处理：
先 existsSync(absolutePath(existing))，缺失则按记录里的原路径 rename（跨设备退化为
copyFile）补写，只有确认目标存在才删临时文件。
新增 test/storage-persist.spec.ts（5 项）：首次上传 / 去重命中且文件在 /
去重命中但文件已丢失（补写而非删除）/ persistBuffer 回归 / 空文件拒绝。
反向验证：临时还原修复后第 3 条立刻失败，恢复后 5 项全过。

二、不可用模型的原因归因不准确（T-WEB-017）
unusableReason() 只要 stats 里有 humanoid 数字就归因于 humanoid，于是一个直接上传的
.glb（骨架完全合规、drivable=true、只是没有 VRM 容器）会被写成
「humanoid 不达标（19/22）」，把审核引向"重新绑定骨骼"而不是"以 VRM 交付"。
实测（跨端验收用真实 PMX→Assimp→GLB，886 KB）：
  修复前 → humanoid 不达标（19/22），未产出 VRM
  修复后 → 未产出 VRM（格式为 GLB；humanoid 覆盖 19/22 已达标），需重新以 VRM 交付才能进入客户端目录
现在按 drivable 区分：不满足 16 根必需骨才归因 humanoid；达标但没 VRM 容器则明确说"已达标"。
新增 2 项单测（model-usability 5 → 7 项）。

三、跨端边界验收（Windows × Web）新增两类场景，双方都断言
  * 不可用模型：真实 PMX 用 Assimp 转 GLB 后入库（等价"转换只产出 GLB"）→
    usable=false、原因准确、**不进入 catalog/export**、defaultModelId 不变；
    包内客户端的 bundle.models 里没有任何非 VRM 模型；
  * 场景 config 只给 {physics:{gravity:{y:-9.8}}} → 服务端补齐默认
    （碰撞体 auto、地面 0.6/45°、静风、相机 follow、环境光 1、出生点 1 条），
    客户端解析后逐项一致。

实测：npm run verify 全绿（契约 6 项 / 35 路由 / 版本 0.7.5 / 27 文件 309 项测试 /
build / 产物级实体注册核对 / 启动冒烟）；跨端集成验收在**发布包起的服务端**上全部通过。
版本 0.7.4 → 0.7.5。

README.md

@@ -10,7 +10,7 @@ OpenDance Studio **阶段一**: Web 管理服务端(NestJS + TypeORM + 现有 My
 
 ## 状态
 
-**阶段一已完成**: T-WEB-001 -> T-WEB-016 全部落地,当前版本 **v0.7.4**(契约 `rest-api 0.5.0`、`websocket-keypoints 0.2.0`、`data-models 0.7.0`、`model-formats 0.5.0`、`skeleton-topology 0.2.0`、`database 0.4.0`)。
+**阶段一已完成**: T-WEB-001 -> T-WEB-017 全部落地,当前版本 **v0.7.5**(契约 `rest-api 0.5.0`、`websocket-keypoints 0.2.0`、`data-models 0.7.0`、`model-formats 0.5.0`、`skeleton-topology 0.2.0`、`database 0.4.0`)。
 
 v0.7.4 修订(**场景功能的真正根因:`Scene` 没有注册进 `ENTITIES`**):
 
@@ -35,6 +35,26 @@ v0.7.4 修订(**场景功能的真正根因:`Scene` 没有注册进 `ENTITIES`**
 4. `web-server/scripts/diagnose-scenes.mjs` 保持不变(默认只读),部署 v0.7.4 后运行它
    可确认 `scenes` 表与列的实际情况。
 
+v0.7.5 修订(**不可用模型的原因归因必须准确**):
+
+1. `unusableReason()` 原来只要 `stats` 里有 humanoid 数字就归因于 humanoid,
+   于是一个**直接上传的 `.glb`**(骨架完全合规、`drivable = true`、只是没有 VRM 容器)
+   会被写成「humanoid 不达标(19/22)」—— 审核界面据此会把修复方向引到"重新绑定骨骼",
+   而实际要做的是"以 VRM 交付";
+2. 现在按 **`drivable`** 区分:确实不满足 16 根必需骨 → 仍报 humanoid 覆盖度;
+   骨架已达标但没 VRM 容器 → 明确说明"已达标,需重新以 VRM 交付";
+3. 新增 2 项单测(5 → 7 项):「humanoid 已达标时**不得**出现『humanoid 不达标』字样」
+   与「`drivable=false` 时仍归因于 humanoid」;
+4. **上传落盘的对称兜底**:`persistTempFile`(动作/模型/场景上传走的通路)在去重命中时
+   会直接删掉刚上传的**唯一副本**并返回旧记录 —— 若记录指向的路径已不存在
+   (换过 `STORAGE_DIR`、只恢复数据库、手工删过文件),上传仍返回 201,
+   但**后续动作预处理 500**(实测 `ENOENT ... .vmd`)、模型分析与缩略图静默失败。
+   `persistBuffer` 早有兜底,这条通路漏了;现按记录里的原路径补写。
+   新增 `test/storage-persist.spec.ts`(5 项)覆盖首次上传 / 去重命中 / **文件已丢失补写**
+   / 内存通路回归 / 空文件拒绝,并做了反向验证(还原修复后该用例立刻失败);
+5. 跨端边界验收(Windows × Web)新增两类场景:不可用模型(真实 PMX 转 GLB 后入库)
+   **不进入** `catalog/export` 且 `defaultModelId` 不变;场景 `config` 缺字段时服务端补齐默认值。
+
 v0.7.4 之后的测试补强(**不改产物,故不新发版本**):
 
 1. 新增 `web-server/test/real-samples.spec.ts`(6 项,opt-in):用仓库根
@@ -464,7 +484,7 @@ npm run dev             # http://localhost:5173(/api 与 /health 代理到 3000)
 cd web-server
 npm run contracts:check   # 契约版本一致性(6 项契约版本 + 35 条路由 + 三端版本号)
 npm run typecheck         # TypeScript 严格检查
-npm run test              # 295 项单元测试 / 25 个文件。分布(VMD 31、模型检查器 29、
+npm run test              # 309 项单元测试 / 27 个文件。分布(VMD 31、模型检查器 29、
                           #   模型压缩包 27、预处理 25、admin-port 16、init-env 16、
                           #   Assimp 定位与安装 13、应用版本 12、目录导出 12、.env 预检 12、
                           #   访问日志 9、MMD 材质对齐 9、stats 容量与编码 9、场景配置 9、