docs(debt): 补记之十一 —— PK 断言要"走迁移路径"才有判别力；★ 并给出可执行形状 + 线上现状实测
① ✅ pi §四 确认，并量化"为什么"（/tmp/pktest 实测）:
全新库: PK 来自 DDL 本身 ⇒ 断言**恒绿**、零判别力
旧 库: 重跑同一份 DDL（CREATE TABLE IF NOT EXISTS 命中已存在表 ⇒ 原样跳过）
⇒ PK 仍是 `PRIMARY KEY (agent_name, platform_id)`
⇒ 两种情形**同一份断言**，差别只在"库怎么来的"
⇒ ★ 判据必须**自己造一个旧库**（老 DDL 建表 → 灌行 → 跑迁移 → 断言），
否则它测的是"DDL 文本对不对"，而那件事**永远成立**
② ★★ 线上现状（2026-09-27 04:0x 实测）—— 正是"改 DDL 对生产静默无效"的现场:
PK 列 = `agent_name , platform_id`（**仍是旧的**）
索引 = `idx_platform_sessions_ws`（在，今天还没被任何重建吞掉）
行数 = 278
⇒ 文件里 PK 写什么，库里都不是那个；而全部测试绿
③ ★ 判据/自检该用哪种读法（两个都实测）:
✅ `pragma_table_info` 的 **pk>0 列按 pk 序号排序**后逐项比对
旧库 ⇒ agent_name, platform_id; 全新库 ⇒ agent_name, workspace, platform_id
✗ `LIKE '%(agent_name, workspace, platform_id)%'` 匹配 PK 文本:
在**旧库（PK 明知是错的）上不命中** ⇒ 判据会"**绿着一个错的库**"
⚠️ pragma 的 pk 顺序**可能与声明书写顺序不同**
（PRIMARY KEY (agent_name, platform_id, workspace) 在 pragma 里就是这个顺序）
⇒ **必须按 pk 序号排序后逐项比**，只比集合会漏掉次序差异
④ ★ 由此给出"迁移后自检"的最小形状（今天可写、现在**红**、修好即绿）:
在 `Migrate` 末尾对 agent_platform_sessions 断言三样:
① pk 列（按序号）== (agent_name, workspace, platform_id)
② idx_platform_sessions_ws 存在
③ 无 agent_platform_sessions_new 残留
★ 与 (a)(b)(c) 的区别: 那些是**测试**断言（要自己造旧库才有判别力），
这一条是**启动路径上的自检** ⇒ **生产也会响** —— 否则缺陷在生产上永远不暴露
校验: go test ./internal/repo/ -run Debt -count=1 ⇒ ok; 临时目录已清
JianFeeeee
8b2c9a8fb8