chore(changelog): 领取 #5264 管理后台任务

修改原因：#5264 后端已部署并验证，管理后台仍保留分类确认入口与 allConfirmed 门禁；原交接文档章节和路径变量写法不符合当前 source 校验。

修改内容：将 frontend_status 迁移 claimed；把路径变量统一为冒号形式，补齐“变更接口/验证证据”标准章节并保留原契约语义。路径：changelogs-v2/2026-07/27_5264_移除核单分类手动确认门禁-修改接口-管理后台.md。

实际验证：validateV2Document 通过；source npm test 46 项、check:path-aliases 与 git diff --check 通过。

changelogs-v2/2026-07/27_5264_移除核单分类手动确认门禁-修改接口-管理后台.md

@@ -6,8 +6,8 @@ consumer: "admin"
 change_type: "修改接口"
 backend_status: "deployed"
 gateway_status: "verified"
-frontend_status: "pending"
-frontend_owner: ""
+frontend_status: "claimed"
+frontend_owner: "hl-ui-pi"
 frontend_ref: ""
 target_release: ""
 verified_at: "2026-07-27"
@@ -24,19 +24,19 @@ base: "dev-v3"
 
 核单流程不再要求财务在八个核单分类上逐一点击“本分类已确认”。管理后台只需要保存各分类明细；明细完整且可用于报账时，即可生成主报账人报账表。旧分类确认查询和确认接口保留兼容返回，但确认状态不再作为主报账、单团核算、Step6 提交或财务确认的门禁。
 
-## 2. 变更清单
+## 变更接口
 
 | # | 接口 | 方法 | 路径 | 变更类型 | 说明 |
 |---|------|------|------|----------|------|
-| 1 | 查询原型八个核单分类确认状态 | GET | `/v3/admin/order/{orderId}/settlement/category-checks` | 修改接口 | 响应字段保留，但 `allConfirmed` / `confirmStatus` 仅用于兼容展示，不再决定后续流程能否继续 |
-| 2 | 按最近读取指纹确认单个核单分类 | POST | `/v3/admin/order/{orderId}/settlement/category-checks/{category}/confirm` | 修改接口 | 标记为废弃兼容；管理后台停止调用并移除“本分类已确认”入口 |
-| 3 | 生成主报账人报账表 | POST | `/v3/admin/order/{orderId}/settlement/reports/reimbursement/generate` | 修改接口 | 生成条件改为核单明细保存完整，不再要求八分类手动确认 |
+| 1 | 查询原型八个核单分类确认状态 | GET | `/v3/admin/order/:orderId/settlement/category-checks` | 修改接口 | 响应字段保留，但 `allConfirmed` / `confirmStatus` 仅用于兼容展示，不再决定后续流程能否继续 |
+| 2 | 按最近读取指纹确认单个核单分类 | POST | `/v3/admin/order/:orderId/settlement/category-checks/:category/confirm` | 修改接口 | 标记为废弃兼容；管理后台停止调用并移除“本分类已确认”入口 |
+| 3 | 生成主报账人报账表 | POST | `/v3/admin/order/:orderId/settlement/reports/reimbursement/generate` | 修改接口 | 生成条件改为核单明细保存完整，不再要求八分类手动确认 |
 
 ## 3. 接口详情
 
 ### 3.1 查询原型八个核单分类确认状态
 
-- **方法 / 路径**：`GET /v3/admin/order/{orderId}/settlement/category-checks`
+- **方法 / 路径**：`GET /v3/admin/order/:orderId/settlement/category-checks`
 - **使用场景**：旧页面或兼容逻辑读取八分类状态。
 - **认证**：需要管理后台登录态；房控角色不可访问。
 - **幂等性**：是，只读查询。
@@ -45,7 +45,7 @@ base: "dev-v3"
 
 ### 3.2 按最近读取指纹确认单个核单分类（废弃兼容）
 
-- **方法 / 路径**：`POST /v3/admin/order/{orderId}/settlement/category-checks/{category}/confirm`
+- **方法 / 路径**：`POST /v3/admin/order/:orderId/settlement/category-checks/:category/confirm`
 - **使用场景**：仅兼容旧前端请求；新管理后台不再调用。
 - **认证**：需要管理后台登录态和财务写权限；房控角色不可访问。
 - **幂等性**：同一分类、同一 `expectedSourceFingerprint` 重复确认返回当前兼容状态。
@@ -54,7 +54,7 @@ base: "dev-v3"
 
 ### 3.3 生成主报账人报账表
 
-- **方法 / 路径**：`POST /v3/admin/order/{orderId}/settlement/reports/reimbursement/generate`
+- **方法 / 路径**：`POST /v3/admin/order/:orderId/settlement/reports/reimbursement/generate`
 - **使用场景**：核单明细保存完整后生成或刷新主报账人报账表。
 - **认证**：需要管理后台登录态和财务写权限；房控角色不可访问。
 - **幂等性**：同一来源数据已生成时，可返回当前报账表；来源变化后重新生成。
@@ -76,7 +76,7 @@ base: "dev-v3"
 
 无请求体。
 
-#### 4.2.2 `POST /category-checks/{category}/confirm`（废弃兼容）
+#### 4.2.2 `POST /category-checks/:category/confirm`（废弃兼容）
 
 | 字段 | 类型 | 必填 | 说明 | 校验规则 |
 |------|------|------|------|----------|
@@ -197,7 +197,7 @@ base: "dev-v3"
 | `584315` | 核单来源数据已变化，请刷新后重新生成 | 报告来源指纹变化 |
 | `584317` | 当前报告状态不允许执行该操作 | 当前核单状态不允许生成或确认报告 |
 | `584319` | 核单存在未知分类或历史迁移数据不完整 | `category` 不是 §6.1 中的值 |
-| `584320` | 核单分类「{categoryName}」明细尚未保存完整或数据不可用于报账 | 生成主报账表时，某个分类明细缺必填业务信息或不可用于报账 |
+| `584320` | 核单分类明细尚未保存完整或数据不可用于报账 | 生成主报账表时，某个分类明细缺必填业务信息或不可用于报账；响应会带具体分类名 |
 
 ## 8. 示例
 
@@ -325,7 +325,7 @@ Authorization: Bearer <token>
 
 - **适用场景**：管理后台核单流程；分类明细已保存完整后生成主报账人报账表。
 - **不适用场景**：继续用 `allConfirmed=true` 作为“生成主报账表”“生成单团核算表”“Step6 提交”“财务确认”的前置条件。
-- **特殊边界**：`POST /category-checks/{category}/confirm` 仍可能返回 200，但它只是兼容旧调用，不代表新流程需要或应该调用。
+- **特殊边界**：`POST /category-checks/:category/confirm` 仍可能返回 200，但它只是兼容旧调用，不代表新流程需要或应该调用。
 - **明细完整性口径**：生成主报账表时，八个分类都必须存在可用于报账的明细快照；缺少分类、金额非法、业务必填项为空或来源数据不可用时返回 `584320`。
 
 ## 10. 修改前后对比
@@ -363,11 +363,18 @@ Authorization: Bearer <token>
 
 ## 12. 注意事项
 
-- 管理后台不要再新增对 `POST /category-checks/{category}/confirm` 的调用。
+- 管理后台不要再新增对 `POST /category-checks/:category/confirm` 的调用。
 - 页面上原“本分类已确认”按钮、确认进度提示和 `allConfirmed=false` 禁用下一步的逻辑可以移除。
 - 查询分类状态接口可继续用于兼容老页面，但不要把 `UNCONFIRMED` 或 `STALE` 解释为主报账表不可生成。
 - 生成主报账表失败时优先识别 `584320`，它表示需要补齐对应分类明细，而不是要求点击分类确认。
 
+## 验证证据
+
+- 后端 PR：[#5274](https://git.1814.love:8443/wx/HL/pulls/5274)。
+- 合并提交：[`8635973e6`](https://git.1814.love:8443/wx/HL/commit/8635973e6)。
+- 实现提交：[`07ac323a1`](https://git.1814.love:8443/wx/HL/commit/07ac323a1)。
+- Source frontmatter 已记录后端部署完成、网关验证通过；前端按本交接独立完成消费与验证。
+
 ## 13. 关联 / 联系人
 
 ### 13.1 链接