docs(ai-review): 更新對話收斂為關閉所有未解決 comment 的說明

README.md

@@ -35,7 +35,7 @@
 11. action 一啟動就先做「前置驗證」（流程第 2 點）：集中檢查 Gitea REST API token、comment token、git push 認證與 LLM 的所有驗證相關設定是否可用，全部通過才往下跑。驗證邏輯獨立成 `app/preflight.js`（git push 驗證委派給 `app/git.js` 的 `verifyRemoteAccess`），由 `main.js` 在 Step1 之後、其餘步驟之前呼叫；任何一項失敗都印出是哪一項、原因為何後 `exit 1`，避免在分析到一半、發 comment 或最後 push 時才因 token / key / 認證無效而中斷
 12. PR 對話收斂（流程第 2.5 點）邏輯獨立成 `app/resolve.js`，由 `main.js` 在前置驗證與自動提交檢查之後以 `Step2` 呼叫：
     - 透過 `app/gitea.js` 的 `listAllReviewComments` 取得所有行內 review comment，`groupConversations` 以「path+line」收斂並偵測 `resolver`（已解決）；`reconcileConversations` 取 PR head 最新檔案內容（`getFileContentAtRef`，contents API base64 解碼）取目標行附近視窗，交 `judgeConversations` 由 AI 批次判為 `resolved` / `false_positive` / `open`
-    - `reconcileConversations` 對所有未解決對話一律呼叫 `resolvePullReviewComment`（`POST /pulls/comments/{id}/resolve`）關閉，再依 AI 判斷把對應 finding 分流：`resolved`→`resolvedFindings`（供移除）、`false_positive`→`excludedFindings`（供寫入 exclusions 並移除）、`open`→`carriedFindings`（加回舊問題）
+    - `reconcileConversations` 先把**每一個未解決的 comment**（有 id 且無 `resolver`，依 comment id 去重；不依賴 `path|line` 分組，故含無 path／position 變 null 者）一律呼叫 `resolvePullReviewComment`（`POST /pulls/comments/{id}/resolve`）關閉，確保每個獨立 thread 都關到；再依 AI 判斷把對應 finding 分流：`resolved`→`resolvedFindings`（供移除）、`false_positive`→`excludedFindings`（供寫入 exclusions 並移除）、`open`→`carriedFindings`（加回舊問題）
     - 與既有 findings 流程的銜接：`main.js` 在 Step4 以 `dropResolvedFindings` 移除（已修復＋誤報）、`addCarriedFindings` 加回仍成立者（以「檔案路徑＋正規化建議內容」為簽章比對，對行號漂移與標點差異穩定）；Step5 以 `findings.js` 的 `appendExclusions` 把誤報寫入 `exclusions.json`（workspace 與 cloned repo 各一份，供本次過濾與後續 commit）
     - 為降低 token 用量只送目標行附近視窗；任一外部呼叫失敗都降級為「視為 open」並繼續流程
 13. AI 助理使用量統計獨立成 `app/usage.js`，於 `Step6` 發布 Review 前蒐集，同時寫入 action log 與 Review 本文，核心是呈現「剩餘可用百分比」：