chore(ai-review): 更新 findings.json 與 exclusions.json

移除本輪已修復(Date.parse 預算、結束碼/sanitizeBody/logger 測試)的 finding;
保留 7 條設計取捨類(重試/錯誤閾值/SRP/並行化/回應大小 DoS 防護);
將 6 條不適用或誤報(Node<16、push.apply、'null' 字串、已用 Set、env 可注入、
Set 轉換)登記至 exclusions。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.gitea/ai-review/exclusions.json

@@ -22,5 +22,41 @@
     "role": "Bard",
     "original_finding": "分隔線字串為魔術字串,硬編碼在模組頂層,不易維護與調整。建議將分隔線管理集中化,並考慮提供動態產生方法。",
     "reason": "不適用。分隔線已是模組頂層的具名常數(LINE/SUBLINE),本即集中管理且為通用良好實務;固定寬度分隔線改為動態產生方法只會徒增複雜度,無實質效益,故不採納。"
+  },
+  {
+    "location": "app/gitea-client.js:63",
+    "role": "Mage",
+    "original_finding": "while 迴圈中使用 AbortSignal.timeout,若 Node.js 版本低於 16 會崩潰。建議改用 AbortController 搭配 setTimeout。",
+    "reason": "不適用。本專案以 node:20-alpine 為基底且 package.json engines 限定 >=18,AbortSignal.timeout 自 Node 17.3 起即支援,執行環境保證可用,無向下相容需求。"
+  },
+  {
+    "location": "app/gitea-client.js:101",
+    "role": "Rogue",
+    "original_finding": "處理分頁資料用 for...of 逐一 all.push(item) 效率不佳,建議用 Array.prototype.push.apply(all, items)。",
+    "reason": "不採納且會造成回歸。先前依 Bard(gitea-client.js:59)建議刻意改用 for...of 以規避展開/apply 在大量項目時的呼叫堆疊上限風險;push.apply 等同展開,會重新引入該風險。逐頁項目數量有限,迴圈開銷可忽略。"
+  },
+  {
+    "location": "app/validate.js:14",
+    "role": "Mage",
+    "original_finding": "isEmptyOrNull 判斷式包含 value === 'null',導致字串 'null' 被判定為空,破壞語義一致性。建議移除對 'null' 字串的特殊判定。",
+    "reason": "不採納。此為刻意保留原 bash 版本 is_empty_or_null 的語義:Gitea/jq 等來源可能將未設定值輸出為字串 'null',視其為空可避免把字面 'null' 當成有效設定。移除會改變既有行為。"
+  },
+  {
+    "location": "app/tags.js:46",
+    "role": "Rogue",
+    "original_finding": "cleanupOrphanTags 在迴圈中重複掃描所有 release 名稱陣列,複雜度 O(tags*releases),建議改用 Set。",
+    "reason": "誤報。cleanupOrphanTags 已將 releaseTagNames 交給 categorizeTags,後者於進入迴圈前即建立 Set 進行 O(1) 查找;並無 O(tags*releases) 的重複掃描。"
+  },
+  {
+    "location": "app/config.js:33",
+    "role": "Leo",
+    "original_finding": "直接將 env 預設為 process.env,全域相依性可能導致難以追蹤的副作用,建議抽離為 Provider 或 ConfigFactory。",
+    "reason": "不適用。loadConfig 已將 env 設為可注入參數(預設 process.env),測試即透過傳入假 env 驗證,已具良好可測性與隔離;對此規模的 Action 引入 Provider/Factory 屬過度設計。"
+  },
+  {
+    "location": "app/tags.js:21",
+    "role": "Leo",
+    "original_finding": "categorizeTags 內部頻繁轉換 Set,若被頻繁呼叫可能造成效能浪費,建議改為接收已轉好的 Set。",
+    "reason": "不適用。categorizeTags 每次清理流程僅被呼叫一次,單次建立 Set 成本可忽略;讓純函式自行建立 Set 可保持介面單純,將轉換責任外推反而增加耦合。"
   }
 ]