fix: ship loc_additions thresholds so the new batch metric takes effect

[lis186]

變更說明

Closes #2。

#1 引入了 loc_additions（以「新增行數」評估批量，優先於 loc_changes），但沒有任何設定檔範例帶這個欄位，所以 init.ts:298 從每個 template 讀到的都是 undefined，這個判準在預設安裝下永遠不生效。使用者要自己手改 YAML 才能啟用，而 YAML 裡沒有範例可抄。

加到全部六份出貨設定檔——三個 preset 加上根目錄的 .gitlab-analysis.example.yml 與 examples/gitlab-configs/ 下的兩份，因為後三份才是使用者實際會拿去抄的。另補 src/presets/README.md 的說明。

閾值數字沿用各檔既有的 loc_changes

不發明新比例。additions ≤ additions + deletions 恆成立，所以同一組數字套在「只算新增」上只會讓評級變寬鬆、不會變嚴格——既有專案升級後不會突然被降級。數字之後可依實際分佈再調。

安全性檢查清單

• 我已確認沒有提交任何敏感資訊（tokens, passwords, 內部 URLs）
• 我已確認沒有包含真實的公司/專案名稱
• 我已使用 .env 管理所有配置資訊
• 我已執行 ./scripts/check-secrets.sh 並通過檢查
• 我已執行測試並通過：npm test

check-secrets.sh 的檔案內容掃描 ✅ 通過。所有數字為設定閾值，無真實團隊資料。

測試計畫

驗收條件不是「YAML 有那幾行」，而是它真的被讀進去並生效。 這個 repo 有反例：release_interval_days 與 code_freeze_days 出現在每一份設定檔、卻不在 ThresholdsSchema 內，載入時被 zod 靜默 strip，而凍結期評估其實讀的是硬編碼常數（見 #6）。驗證通過不代表欄位有生效，所以實測了六份設定檔：

$ ./bin/run.js release:analyze -p group/project --config <每一份> --show-config
閾值設定:
  MR 數量:
    健康: < 50
    警告: <= 100
    危險: > 100

新增行數（生效中，優先於 LOC 變更）:     ← 這一段以前永遠不會印
    健康: < 5000
    警告: <= 10000
    危險: > 10000

LOC 變更（未使用：已由新增行數取代）:
    健康: < 5000
    警告: <= 10000
    危險: > 10000

六份全部印出「生效中」，且 loc_changes 被正確標記為已被取代。

自動化驗證：

npx tsc --noEmit                          # 0 錯誤
npx vitest run --no-file-parallelism      # 81 檔 / 1192 passed / 16 skipped（原 1174）

新增 tests/unit/presets/shipped-config-thresholds.test.ts（18 個測試）。它從磁碟讀真實的出貨設定檔再過 ThresholdsSchema，所以兩種退化都抓得到：

1. 有人從設定檔移除 loc_additions
2. 有人動了 schema 使它在載入時被 zod strip

第 2 種特別重要，因為 safeParse 在欄位被 strip 時仍然回傳 success——測試斷言的是 result.data.loc_additions 存在，不只是驗證通過。

突變測試（兩種退化各驗一次）：

突變	結果
從 mobile-app.example.yml 移除 loc_additions	3 紅（該檔的 3 條測試）
從 ThresholdsSchema 移除 loc_additions	6 紅（六份檔案的 schema 保存測試）

第三組測試釘住「loc_additions 的閾值不得比 loc_changes 嚴格」，作為上述「升級不應讓既有專案降級」這個承諾的迴歸保護。

相關 Issue

Closes #2