FR-107.3 T-3.1 分類結果表改掛批次：加批次編號、輪次、目標集快照，資料夾編號改可空、對外定址改 uid

建議 model：opus／effort：medium — 改的是既有生產資料表，舊資料與既有報表不可以壞。

本卡屬 FR-107（母卡 CM-1843）第 .3 棒（子需求卡 CM-1846），子任務 T-3.1：把「分類結果」這張既有的表從綁 Google Drive 資料夾改成綁批次。

這張卡做什麼（白話）

系統已經有一張表 evidence_classification_runs 存「每一次分類跑完的結果」。現在它是用 Google Drive 資料夾編號當主要識別的（run_folder_id，而且是 NOT NULL）——沒有 Drive 就存不進去。

這張卡把它改成綁批次：加 batch_id（哪個批次）、round_id（哪個稽核輪次）、catalog_snapshot（這次送給 AI 的檢查點清單快照）、prompt_snapshot（這次實際用的 AI 指令三段），並把 run_folder_id 改成可以留空，對外定址改用 uid。

為什麼要存快照：報表要算「AI 判得準不準」，如果之後有人改了 SSP（系統安全計畫）的內容，檢查點清單會變，報表就會用新清單去對舊結果，數字會亂。存快照之後報表讀當時的那份，不受事後改動影響。

🔴 舊資料一筆都不能壞：POC 上有既有的分類結果，FR-031 那兩份報表還要打得開（D3 決定並存一版）。

動哪些檔／表

套件（走 path dependency 開發）
~/Projects/Jedicogy/module/jedi-python-package/jedi-evidence-classification/
  .../infra/model/classification_run_model.py
      :16 run_folder_id  NOT NULL 自然鍵  ← 改可空、UNIQUE 改 partial
      :21 ap_uid                          ← 保留給舊列，不動
      :23 framework_id 預設 'cmmc-l1'     ← 本卡不動（T-5.2 處理硬編碼）
      :38-39 report_original / state JSONB ← 保留
      ← 加 batch_id / round_id / catalog_snapshot / prompt_snapshot
  對應 entity ＋ repo：加 get_by_uid()、get_latest_by_batch()

主專案
scripts/sql/packages/jedi_evidence_classification/00N-runs-attach-batch.sql  ← 新增

五處改動（design.md §6.1.4）

改動                                  說明
run_folder_id NOT NULL → NULL         舊列保留值；新列為 NULL。
                                      既有 UNIQUE／自然鍵約束改為 partial：
                                      ... WHERE run_folder_id IS NOT NULL
新增 batch_id int NULL FK→evidence_batches.id
                                      新列由應用層保證非空；舊列 NULL
                                      （同套件內的表，可以建 FK）
新增 round_id int NULL                軟參照（另一支插件的表，不建 FK）
新增 catalog_snapshot JSONB NULL      run 當時送 AI 的目標集
                                      （含 part_id／group_id／group_title／字母）
                                      報表讀這份，不重算
新增 prompt_snapshot JSONB NULL       三段 prompt 實際內容（persona／guidance／hints）
                                      除錯與稽核用
定址                                   新 route 一律 /classification-run/<run_uid>/...
                                      uid 已在 BaseModel 慣例欄位內

state JSONB 內的 key（本卡先定規格，實際改在 T-3.3）
  檔案 key：Drive file id → file_uid
  AO key： AC.L1-3.1.1[a] → part_id（AC.L1-3.1.1_obj.2）
  每筆保留 ao_letter 供顯示

一個批次可以有多次 run（重新分類），evidence_batches.current_run_id 指最新那一次。

怎麼做（逐步）

① 改 UNIQUE 約束時順序要對：先 DROP CONSTRAINT（或 DROP INDEX）→ 再建 partial UNIQUE（... WHERE run_folder_id IS NOT NULL）→ 再 ALTER COLUMN run_folder_id DROP NOT NULL。順序錯會被既有約束擋住。
② 加欄位全部 nullable，不要加 NOT NULL（舊列填不了）。新列的非空由應用層保證。
③ repo 加兩支查詢：get_by_uid(uid)、get_latest_by_batch(batch_id)。先 grep 既有 repo 有沒有同功能不同名的方法（按行為 grep，例如 grep run_folder_id 找現有的查法），有就 extend 不要另開一隻。
④ 套 DEV：psql -h localhost -p 5432 -U cmmgr -d guidant_ai_dev --single-transaction -v ON_ERROR_STOP=1 -f <檔>；收尾 INSERT public.schema_migrations。
⑤ 套完立刻驗舊資料：SELECT count(*) FROM ... WHERE run_folder_id IS NOT NULL 筆數與套之前一致、值沒變。

驗收條件

DEV 套完舊列的 run_folder_id 值仍在（逐筆比對套前套後的筆數與抽樣值），新增的四個欄位全 NULL。