还原后端构建提交号注入

docs/project/backend-development-guidelines.md

@@ -334,11 +334,9 @@ INTERNAL_ONLY
 ```bash
 cd server
 ./mvnw test
-TH_HOTEL_BUILD_COMMIT=$(git rev-parse --short HEAD) ./mvnw verify
+./mvnw verify
 ```
 
-中文说明：`./mvnw test` 用于日常开发和普通回归；`verify` 会进入部署包生命周期，必须提供真实 `TH_HOTEL_BUILD_COMMIT` 且 Git 工作区干净，否则会在 `prepare-package` 阶段失败。测试机 / UAT / 生产打包优先使用仓库根目录的 `scripts/package-server-with-build-info.sh`。
-
 聚焦开发时可先运行相关测试：
 
 ```bash
@@ -379,4 +377,4 @@ cd server
 - [ ] 是否没有提交真实 Secret 或客户数据？
 - [ ] 是否没有把 Provider 输出直接当业务事实？
 - [ ] 是否运行了 `./mvnw test` 或说明了无法运行原因？
-- [ ] 是否在干净工作区运行了带 `TH_HOTEL_BUILD_COMMIT` 的 `./mvnw verify`，或说明了无法运行原因？
+- [ ] 是否运行了 `./mvnw verify` 或说明了无法运行原因？

docs/project/go-live-notes.md

@@ -43,7 +43,7 @@
 上线前至少确认以下事项：
 
 - 当前分支、提交和部署包来源清楚，不能混入本地临时文件、真实 Secret、真实客户邮件样本或构建产物；测试机 / UAT 构建包必须在本次代码提交后再打包，且能通过 `GET /api/health` 的 `build_commit` 证明当前运行提交。
-- `server` 后端通过完整检查：在干净 Git 工作区执行 `cd server && TH_HOTEL_BUILD_COMMIT=$(git rev-parse --short HEAD) ./mvnw verify`，或使用仓库根目录 `scripts/package-server-with-build-info.sh` 生成部署包。
+- `server` 后端通过完整检查：`cd server && ./mvnw verify`。
 - 生产或 UAT 数据库已经备份，并确认 Flyway migration 只新增不修改历史脚本。
 - 所有 Secret 都通过环境变量、部署平台 Secret 或密钥管理系统注入，不写入仓库、镜像、前端环境变量或普通配置文件。
 - 生产默认不保存 AgentBus raw frame 样本。
@@ -63,13 +63,12 @@
 
 | 变量 | 是否 Secret | 上线注意事项 |
 | --- | --- | --- |
-| `TH_HOTEL_BUILD_COMMIT` | 否 | 构建包时必须设置为已提交后的当前 Git commit；推荐在仓库根目录执行 `scripts/package-server-with-build-info.sh -DskipTests`，由脚本自动从干净工作区的 `HEAD` 注入。该值会写入 Jar 内嵌 build-info，`/api/health` 返回内嵌值；未设置或不是有效 Git commit 时，`server` 的 `package` / `verify` 会在打包前失败，不允许继续产出 `build_commit=UNKNOWN` 的部署包。不要用未提交工作区代码打包后仍标记旧 HEAD，否则 build commit 只能证明旧提交，不能证明本次修复。 |
+| `TH_HOTEL_BUILD_COMMIT` | 否 | 构建包时设置为已提交后的当前 Git commit，例如 `TH_HOTEL_BUILD_COMMIT=$(git rev-parse --short HEAD) ./mvnw clean package`；该值会写入 Jar 内嵌 build-info，`/api/health` 返回内嵌值；未设置时 `/api/health` 返回 `build_commit=UNKNOWN`，不能作为“已部署指定提交”的证明。不要用未提交工作区代码打包后仍标记旧 HEAD，否则 build commit 只能证明旧提交，不能证明本次修复。 |
 
 说明：
 
 - `GET /api/health` 会返回 `runtime_marker`、`build_commit`、`build_time`、`build_version`，这些字段不包含 Secret，只用于部署排查；`build_commit` 应以构建阶段写入 Jar 的 build-info 为准，不把运行时临时环境变量或未提交工作区状态当作已部署代码证明。
 - 应用启动日志也会输出同一组 build info；如果测试机接口不可访问，可先看启动日志确认运行包。
-- 测试机 / UAT / 生产 Jar 必须从干净 Git 工作区打包；当前 POM 会在 `prepare-package` 阶段校验 `TH_HOTEL_BUILD_COMMIT` 是否是有效 Git commit，并校验工作区是否干净。工作区 dirty、CI 没有 Git 提交信息或人工忘记注入 commit 时，打包应直接失败并重新走标准打包流程。
 - 如果 `build_commit` 不是预期提交，先修部署或重新打包，不要继续改业务逻辑。
 
 ### 3.1 数据库