feat(operations): add auditable source provider maintenance

vehicle-data-platform/docs/vehicle-data-platform-meeting-todo.md

@@ -374,10 +374,21 @@
 - 11 个未绑定来源仍保留在数据差异中心的 11 条 `UNBOUND_SOURCE` 待处理工单中；它们只能通过身份绑定流程进入正式车辆集，不能继续造成 1,035 辆的错误口径。
 - Go 全量测试、前端 49 个文件/259 项测试、TypeScript/Vite 生产构建、Web 资产烟测及四个 systemd 单元状态检查通过。
 
+提供方维护能力（release `source-provider-collation-hotfix-20260716195830`）：
+
+- 运维诊断页允许管理员按具体车辆、协议和独立终端维护提供方名称；前端仍只提交 SHA-256 `sourceRef`，原始 `source_key` 仅在服务端解析和保存。
+- 提供方名称变更必须单独填写权威终端清单、厂商确认记录等核验依据。核验依据与启停/优先级的策略备注是两个独立字段和审计事实；只改提供方不会清空或改写已有策略备注。
+- 迁移 `019_vehicle_source_provider.sql` 已在生产应用，保存当前提供方投影和不可变版本审计。来源诊断与接入管理优先采用该人工核验值，再回退实时平台名或当前来源编码。
+- operator 可查看单车来源诊断但不能写入，viewer 被拒绝，只有 admin 可维护；缺少核验依据的请求返回 `SOURCE_PROVIDER_REASON_REQUIRED`，且乐观版本不会变化。
+- 首次发布在生产真实请求中发现网关来源表与平台表排序规则不同，已改为 VIN/协议/source key 的二进制精确关联；修复后单车诊断和接入明细均恢复，未通过模糊或降级匹配绕过。
+- 生产烟测以 `LB9A32A21R0LS1464` 的既有 `g7s` 识别结果写入同义规范值 `G7s`：策略版本 `v1→v2`，提供方审计包含核验依据，原策略备注保持不变，接入明细立即显示 `JT808 / G7s`，响应中不存在 `sourceKey`。平台、两类告警评估器和对账定时器均为 active。
+- Go 全量测试、前端 49 个文件/259 项测试、TypeScript/Vite 生产构建和 23 个当前 Web 资源门禁通过。
+
 剩余业务资料依赖：
 
-- 当前仍有 111 辆 JT808 提供方缺失。65 辆注册报文携带厂商码 `70504`，但生产中该编码同时对应 G7s、东方北斗和赛格，不能唯一映射；110 辆在 OneOS 只标记为“氢气智能管理平台”，这是聚合来源而非终端提供方；非当前来源中也没有额外 `source_code` 可补齐。
-- 因此这 111 辆继续留在待处理队列，需 GPS 运维/厂家提供 phone/终端到提供方的权威清单。平台不会根据终端号、IP、位置或厂商码猜测提供方。
+- 当前动态复核仍有 104 辆 JT808 提供方缺失。注册报文厂商码在生产中同时对应 G7s、东方北斗和赛格，不能唯一映射；OneOS 只标记为“氢气智能管理平台”，这是聚合来源而非终端提供方。
+- 进一步只读核对 `lingniu_prod` 后确认：旧 `tab_truck_device_info`、`view_addgpsdata`、`historical_data` 设备厂家表当前均无有效数据；仅存的 `v_vehicle_daily_stats.source=G7S/TBOX/NONE` 最晚截至 2025-12-08，属于历史里程来源，不能证明 2026 年当前终端提供方。
+- 因此这 104 辆继续留在待处理队列，需 GPS 运维/厂家提供当前 phone/终端到提供方的权威清单。平台不会根据终端号、IP、位置、旧里程来源或厂商码猜测提供方。
 - 另有 8 辆 OneOS 车型主数据本身无品牌，需资产资料责任人补录后再通过正式 API 同步。
 
 目标：