💡 清理本次改动注释中的票据引用与设计叙述

注释只写从代码看不出来的事实：删除票号引用、设计权衡与取证经过，
保留业务约束（id_card_no 为 NULL 表示未采集、唯一索引覆盖软删除行、
driving_vehicle 为 ALWAYS 策略等）。

doc/sql/transport/blade_transport_driver_profile_account_20261023.sql

@@ -1,7 +1,7 @@
 -- ----------------------------
 -- 司机档案与登录账号打通（2026-10-23）
 -- ----------------------------
--- 三处结构变更，均在单据「07 数据模型迁移」内：
+-- 三处结构变更：
 -- ① user_id 加唯一索引 uk_transport_driver_user —— 一个账号只能对应一条司机档案。
 -- ② id_card_no 放宽为可空 —— NULL 表示「身份证号尚未采集」，是判断档案是否完善的口径。
 --    uk_transport_driver_id_card 保留：MySQL 唯一索引对多行 NULL 不去重，
@@ -11,7 +11,7 @@
 --    NULL 表示改造前存量（来源未知，不臆造）；account_bound_time 是档案与账号建立关联的时点。
 --
 -- 只做结构变更，不回填数据：存量档案的 profile_source / account_bound_time 一律保持 NULL。
--- 判定「档案是否采集」用 id_card_no IS NULL，不另加标记列（见票 01）。
+-- 判定「档案是否采集」用 id_card_no IS NULL，不另加标记列。
 --
 -- 幂等：每段先查 information_schema，条件已满足即跳过，重复执行不报错；
 -- 全部用 PREPARE 动态语句而非存储过程，因此不需要 DELIMITER——按分号逐句切分的客户端
@@ -20,7 +20,7 @@
 -- 前置检查（user_id 有重复时，第 1 节会以
 --   Duplicate entry '<值>' for key 'blade_transport_driver.uk_transport_driver_user'
 -- 失败并终止；此时本脚本对表零修改，先修数据再重跑）：
--- 唯一索引统计**全表**行，含 is_deleted = 1 的软删除档案。票面给的 is_deleted = 0 口径
+-- 唯一索引统计**全表**行，含 is_deleted = 1 的软删除档案：只按 is_deleted = 0
 -- 只能发现活跃重复，软删除行之间的重复同样会让第 1 节失败：
 --   SELECT user_id, COUNT(*) AS dup_count FROM `blade_transport_driver`
 --    WHERE user_id IS NOT NULL