[P2] 重審未再次找到問題不等於已修復：修正 resolved 的狀態與文案

[frankekn]

問題／使用者影響

基準：main@d333e4eb4c286e04ac1ae9ff4635d997b97232b7。src/adapters/github.ts::matchFindings() 以 file、category、正規化 title 與 ±10 行比對；上一輪 finding 沒匹配到就增加 resolvedCount，round comment 顯示 resolved。

這只能證明「這輪未匹配」，不能證明問題已修好。改標題、行號移動、模型漏報、部分 deep pass 失敗，均可能造成同樣結果。對非技術使用者，顯示綠色「已修復」尤其容易被當成安全保證。

這是程式碼語意檢視；沒有宣稱本次觀察到某個真實 PR 因此被誤合併。

第一版最小解法（不新增模型呼叫）

1. 現有跨輪比對結果改用 notRediscovered／「本輪未再次發現」表達；只有目前明確重新找到的問題顯示「仍存在」，未匹配前次的現有 finding 顯示「新發現」。
2. 不把「這輪沒有 findings」自動翻譯成「上輪問題全部已驗證修復」。整體 verdict 仍由這一輪實際結果和 coverage 決定，未完成依 [P1] 未完成審查不得通過合併閘門：統一 needs_human 的 check 與退出狀態 #145。
3. 未完成／部分 coverage 的 review，尤其不能把未覆蓋區域的前次問題報成 resolved；必要時加單一「未完成比對」提示，不推測每個檔案已清除。
4. 修改 matchFindings 的輸出、render.ts、review body、round comment 與測試；先檢查 exported API／state marker 的相容性。舊欄位若需兼容可保留讀取與 deprecated alias，但人類介面不再誤稱。
5. 舊 state marker 仍可讀取；若必須升版，新增明確 version 分支，對未知版本安全回退。不要把歷史狀態全清掉後重發所有留言。

後續才做的事

verified_fixed 只在已有能檢查原 trigger 是否消失的證據流程時提供。先不實作新模型 verifier、不大改 finding identity、不引入語意搜尋／資料庫。不要為了更漂亮的名稱，要求 critic 回傳新 opaque ID 而改變既有匹配契約。這張 issue 可在完成誠實文案與狀態後關閉，真正的修復驗證另立可衡量需求。

驗收／回歸測試

• 程式碼沒有修正但模型這次沒再報：顯示「本輪未再次發現」，不是「已修復」。
• title 改寫、移動超過 ±10 行、category 改變：不誤称驗證修復，也不放寬 admission 規則。
• 本輪 deep pass 失敗：不綠色宣告未覆蓋問題已解決。
• 本輪確實重新找到的問題仍列為 open；dedupe 與新問題行內留言維持既有行為。
• cached render、GitHub summary、round comment 使用一致措辭；歷史資料可安全讀取。
• 使用者理解「本輪未找到」與「已驗證修复」是不同強度的結論。

不做的事／交付

不新增持續運作服務、多 agent 辯論、複雜 finding graph 或自動關閉 GitHub review threads。先完成 output/state 語意修正，保留 core finding/verdict 不變；依實際 diff 宣告相應 gate。和 #102 的 delivery dedupe 分開：這張管「狀態說了什麼」，#102 管「結果是否完整送達」。