docs(changelog): 订正 #8576/#8601/#8577 三份交接件的编造内容与 frontend_status

三份都是既有条目（#8576/#8601 由 da562f3 批次产出，#8577 单独产出），本次逐条对源码与
测试服实测记录核对后订正，不新增条目。

#8576
- frontend_status 由 not_required 改回 pending（ca26be4 批量置位）。依据：hl-ui
  origin/v2.1 确有 src/api/fleet/group-dispatch.js 消费 reconfigure / confirm 两个端点，
  而全仓 specWarnings 命中数为 0 —— 新字段目前无人渲染，车辆规格提醒对车务不可见。
  改判原因已按 FRONTEND_CONSUMPTION_STATUS_GUIDE 要求写进 status_note。
- 两处错误响应示例的 message 是编造的，换成 GroupDispatchAdminErrorCode 的真实模板。
- planVersion 出参类型 Integer/Long 统一为 Long（两张表）。

#8601
- 删掉四处「589535 适用于本端点」的错误断言。实证：RequirementService.java:4749 对
  resourceType=VEHICLE 硬编码 hasActiveAssignments=false，该码在车需求打回上结构性不可达。
- 编造的订单 ID 2099459272533323777 换成实测的 2105173274755534850（dispatch）与
  2105173313083080706（reject）。
- 错误码集合订正为 809000 / 809007（仅 dispatch）/ 582031 / 582083。

#8577
- 订正一处「POST requirement/confirm 零影响」的错误断言：doConfirm 与 confirm-check 共用
  已收窄的 classifyVehicleSubmission，该端点的 809122 触发条件同步收窄。
- 809121 / 809123 的错误响应示例换成测试服实测原文。
- frontend_status 保留 not_required，但把判定依据写进 status_note：三个码一律走拦截器透
  message、生产代码无一处按报文匹配、前端也无纯接送机户的规避需要撤除；同时列出五处现已
  陈旧的前端注释与一处 mock 报文，供 mmg 顺手清理。

门禁：validate-changelog-frontmatter.mjs --files 三个文件一次通过（PASS: 3 files）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

changelogs-v2/2026-09/30_8576_团期配车提交与确认响应新增车辆规格提醒清单-修改接口-管理后台.md

@@ -7,12 +7,12 @@ author: "wx(GIT)"
 change_type: "修改接口"
 backend_status: "deployed"
 gateway_status: "verified"
-frontend_status: "not_required"
+frontend_status: "pending"
 frontend_owner: ""
 frontend_ref: ""
 target_release: ""
 verified_at: ""
-status_note: "PR #8602 已 squash 合并 dev-v3（cfefe04a83），hl-fleet-service dev-v3 分支已滚测试服。纯新增字段，两个端点的既有字段、错误码、HTTP 形态全部未变。"
+status_note: "PR #8602 已 squash 合并 dev-v3（cfefe04a83），hl-fleet-service dev-v3 分支已滚测试服。纯新增字段，两个端点的既有字段、错误码、HTTP 形态全部未变。【2026-09-30 由 not_required 改回 pending，原因】前端确实消费这两个端点：hl-ui origin/v2.1 有 src/api/fleet/group-dispatch.js（reconfigure / confirm 各一个调用点），而全仓 specWarnings 命中数为 0 —— 即新字段目前无人渲染，提醒对车务不可见，需要前端补渲染后本条才算落地。"
 updated_at: "2026-09-30"
 base: "dev-v3"
 ---
@@ -102,7 +102,7 @@ base: "dev-v3"
 | `groupBatchId` | String | 团期主订单 ID（雪花，字符串） |
 | `requirementId` | String | 正式团级用车需求 ID（雪花，字符串） |
 | `requirementVersion` | Integer | 正式团级用车需求版本 |
-| `planVersion` | Integer/Long | 团期计划版本 |
+| `planVersion` | Long | 团期计划版本 |
 | `addedCount` | Integer | 新增派车记录数 |
 | `removedCount` | Integer | 软删派车记录数 |
 | `keptCount` | Integer | 保留未变派车记录数 |
@@ -264,12 +264,12 @@ base: "dev-v3"
 
 #### 错误响应
 
-既有错误码一条都没变。示例（分组不在本团需求内）：
+既有错误码一条都没变。示例（分组不在本团需求内，消息模板 `乘车分组不存在于本团正式需求: {0}`）：
 
 ```json
 {
   "code": 602001,
-  "message": "分组 VAN 不在本团正式用车需求的分组清单内",
+  "message": "乘车分组不存在于本团正式需求: VAN",
   "success": false,
   "data": null
 }
@@ -317,7 +317,7 @@ base: "dev-v3"
 | `alreadyConfirmedCount` | Integer | 确认前就已是「已确认」的配车行数（重复确认时全部落在这里） |
 | `requirementId` | String | 本次确认所依据的正式团级用车需求 ID（雪花，字符串） |
 | `requirementVersion` | Integer | 本次确认所依据的需求版本 |
-| `planVersion` | Integer/Long | 当前团期计划版本（确认不改计划，故不递增） |
+| `planVersion` | Long | 当前团期计划版本（确认不改计划，故不递增） |
 | `requirementAdvanceIntent` | String | 已登记的需求回写意图方向，恒为 `CONFIRMED_TO_DISPATCHED` |
 | `coverage` | Object | 按乘车分组的覆盖明细（确认前对库里现存配车行重判一次的结果），结构同 reconfigure |
 | `legacyGroupRowCount` | Integer | 本团存活派车行里没有乘车分组键的历史行数；非零时 602008 的缺口很可能正是它们造成的 |
@@ -423,12 +423,12 @@ base: "dev-v3"
 
 #### 错误响应
 
-既有错误码一条都没变。示例（现存配车对当前需求仍不完整）：
+既有错误码一条都没变。示例（现存配车对当前需求仍不完整，消息模板 `配车尚未覆盖完整, 不能确认: {0}`）：
 
 ```json
 {
   "code": 602008,
-  "message": "现存配车对当前需求仍不完整：分组 BUS 缺 2026-09-15",
+  "message": "配车尚未覆盖完整, 不能确认: 乘车分组 BUS 的服务日未排满, 缺失: [2026-09-15]",
   "success": false,
   "data": null
 }