用「业务文案覆盖率」做了一次整体核对：提取 Java 侧 service 与 auth 目录下的全部
59 条业务文案，与 NestJS 实际抛出的文案比对，找出未覆盖项逐条追查。
这个方法能发现契约对拍覆盖不到的规则——对拍只走典型路径，
触发条件苛刻的分支（例如连续失败 20 次）不会被跑到。

发现并修复：登录锁定的响应完全不同
  Java    429「登录失败次数过多，账号已被临时锁定，请约 X 小时后重试或联系管理员解锁」
  NestJS  401「账号或密码错误」
被锁定与密码错误是两回事：使用者必须知道自己被锁了、还要等多久、可以找谁解锁，
否则只会反复重试。剩余小时向上取整且至少为 1，避免出现「请约 0 小时后重试」。
已用连续 20 次失败的实测验证两边一致：第 20 次 401，第 21 次 429 且文案逐字相同。

一并补齐
- 数据库结构与代码不匹配（Prisma P2021/P2022）时返回「数据库字段未同步，
  请完成数据库迁移后重试」，而不是笼统的服务器故障，提示指向真正的原因
- 图片目录创建失败、图片写入失败、缩略图回写失败三处 IO 异常的文案与 Java 对齐

核对后确认无需处理的 8 条
「XX 新增失败」五条是 Java 的 insert 计数防御检查，Prisma 写入失败会直接抛异常，
两边最终都返回 500 通用文案，行为一致；「认证签名密钥未配置」同样走 500 兜底；
「页面权限无法保存」是 JSON 序列化失败的兜底，Prisma 侧不存在这一环节。

回归：契约比对 31/31、设备流程 15/15、企微规则 10/10、单元测试 25/25 全部通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>