用户审核不通过原因

背景

平台目前只支持“待审核”和“审核通过”两种用户审核状态，管理员无法明确记录商家或骑手资料审核不通过的原因。后续用户端需要根据审核结果提示用户补充资料，但本次不修改 App 前端。

目标

用户审核状态增加“审核不通过”。
管理员审核商家或骑手资料不通过时，必须输入具体原因。
原因随用户信息返回，供后续 App 展示和资料补充流程使用。

数据模型

info_user.audit_status 状态语义：
- 0：待审核。
- 1：审核通过。
- 2：审核不通过。
info_user 新增 audit_reject_reason TEXT NULL，Java 属性名为 auditRejectReason。
不对审核不通过原因设置应用层字符数限制。
当审核状态不是 2 时，保存操作必须将 audit_reject_reason 清空，避免旧原因与当前状态不一致。

平台管理端

修改商家审核页 sjuser.vue 和骑手审核页 peisus.vue。
审核状态选项增加“审核不通过”。
选择“审核不通过”时显示多行文本输入框，由管理员按实际情况自由填写。
原因去除首尾空白后为空时禁止提交，并显示国际化错误提示。
选择“待审核”或“审核通过”时隐藏原因输入框，提交前清空旧原因。
新增用户可见文本必须补齐简体中文、繁体中文、英文和越南语。

后端行为

平台新增和修改用户接口继续使用 POST /infouser/user、PUT /infouser/user，两者执行同一审核原因校验。
当 auditStatus = "2" 时，auditRejectReason 去除首尾空白后必须非空；否则返回国际化业务错误，不更新用户。
当 auditStatus 不等于 "2" 时，后端主动将 auditRejectReason 设为 null，不能只依赖前端清理。
用户列表、平台用户详情和 App 用户信息接口沿用现有 InfoUser 返回结构，新增返回 auditRejectReason。
App 资料更新接口 /infouser/user/setuser 不接受客户端提交的审核状态，防止用户自行改变审核结果。
/infouser/user/setuser 接收非持久化标记 updateUserInfo；仅当资料保存成功、该标记为 true 且数据库当前审核状态为 2 时，将审核状态原子更新为 0 并清空 auditRejectReason。
updateUserInfo 为 false、null，或用户当前并非审核不通过时，不改变审核状态。
Entity、MyBatis resultMap、查询、插入和更新映射全部补齐该字段。

数据库变更

只将迁移 SQL 写入 updatesql/sql.md，不直接执行数据库变更。
SQL 为 info_user 新增 audit_reject_reason TEXT NULL。
为 sys_user_audit 字典新增值 2，标签为“审核不通过”，供平台审核状态选项使用。

验收标准

商家和骑手审核页均能选择“审核不通过”。
选择“审核不通过”但未填写有效原因时，前端和后端都拒绝保存。
填写原因后可以保存，重新打开用户资料时能正确回显。
将状态改为“待审核”或“审核通过”后，数据库中的旧原因被清空。
getuserinfo 等返回用户信息的现有接口包含 auditRejectReason。
本次不修改商家或骑手 App 前端。
审核不通过的用户携带 updateUserInfo=true 成功补充资料后恢复为待审核并清空旧驳回原因；普通资料更新不改变审核状态。

非目标

不提供固定原因或预设原因选项。
不建立审核历史记录表。
不记录每次审核的管理员、时间或历史原因。
不实现 App 端红色提示、资料高亮或字段只读控制。