refactor: 移除已廢棄的自管加密金鑰機制（credential 全面託管 CF Workers Secrets）

leo 2026-07-20 明令：「已經改用 cf 自己的 secrets，不要再說它了」
「我希望以後再也看不到這個詞再出現」

背景：credential 早已遷移至 CF Workers per-script Secrets + D1 目錄，
舊的自管金鑰（client 端 AES-GCM + KV 密文 + crypto_decrypt）是遷移期遺留。
本次連根移除，含一併作廢的死 SaaS 碼。

移除：
- 舊 KV 密文解密路徑（credential-injector.ts 整檔、dual-read fallback）
  前置驗證：leo21c / youlin 兩帳號 CREDENTIALS_KV 實測 *:cred:* 皆 0 筆
- migrate-to-workers-secrets 搬家端點（回填已完成，無可回填）
- /register 路由與 generateApiKey（HMAC 產 ak_ key 是 SaaS 遺物；
  self-hosted 走 namespace 明碼 D21，已無人使用）
- platform_crypto component（三帳號實測 404 已退役，無 workflow 引用）

保留（附理由）：
- crypto_decrypt 保留為永遠回失敗的 stub——現役三個 auth .wasm 仍宣告該
  import，缺項會讓 WASM instantiate 直接失敗。待零件重編後可真正刪除。

順帶修復（原不在範圍，但會實際壞事）：
- /auth/callback 有 `if (!key) redirect(server_error)` 閘，未設該 secret 的
  實例會登入直接失敗 → 已移除
- OAuth 兩處把 provider token 寫進舊加密 KV（租戶鍵與實際 api_key 在 rotate
  後必然分歧，已失效）→ 改導向 Workers Secrets，包 try/catch 不影響登入
- acr init Standard 模式呼叫已刪除的 /register → 改引導 OAuth 取 key
- .claude/rules 與 system-dev/docs 是同一規範的兩份鏡像，先前只改 rules
  導致鏡像仍在教舊做法 → 已同步（此類雙檔同步應納入檢查）

新用戶安裝從此零 secret 前置。
測試 187/188（唯一 fail 為 pre-existing，stash 驗證與本次無關）；
cypher-executor 與 cli typecheck 全綠。

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

system-dev/docs/5-records/README.md

@@ -1,6 +1,10 @@
 # 5. Records — 日誌 + 驗收報告
 
 > 線上事件復盤、測試報告、決策軌跡。
+>
+> ⚠️ **本目錄是「發生過什麼」的檔案館，不是現行做法**。內容反映當時狀態，其中提及的
+> 機制可能早已移除（例如 credential 的舊自管金鑰路徑已於 2026-07-20 完全移除）。
+> 勿依本目錄任何內容操作；現行規範一律以 `.claude/rules/` 為準。
 
 ## 線上事件
 

system-dev/docs/5-records/incidents/2026-05-29-encryption-key-drift.md

@@ -1,5 +1,8 @@
 # 2026-05-29 credential 解密失敗（兩個 Worker 的 ENCRYPTION_KEY 漂移）
 
+> ⚠️ 歷史記錄（2026-07-20 起本文所述機制已完全移除，本文僅供考古，勿依此操作）。
+> 現行 credential 做法見 `.claude/rules/01-tech-stack.md`「Credential 儲存規範」。
+
 > **症狀**：`acr recipe test kbdb`（credential 注入）回 HTTP 500，`auth_static_key` 回 `credential kbdb_api_key 解密失敗`
 > **根因（主）**：`arcrun-auth-static-key` Worker 的 `ENCRYPTION_KEY` secret 跟正本（cypher-executor / CLI 用的那把）值不同、格式也不同（44-char base64 vs 64-char hex）。AES-GCM 用錯 key 必然解密失敗。
 > **根因（附）**：`component-loader.ts` 用 `res.json().catch(() => res.text())` 讀 response body → body 被讀兩次 → `Body has already been used`。

system-dev/docs/5-records/test-reports/pre-customer-checklist-2026-06-07.md

@@ -1,5 +1,8 @@
 # 交付前自測 Checklist（pre-customer）— 2026-06-07
 
+> ⚠️ 歷史記錄（2026-06-07 當時的清單）。其中 credential 相關步驟所依據的舊自管金鑰機制
+> 已於 2026-07-20 完全移除，**勿照本文操作**；現行做法見 `.claude/rules/01-tech-stack.md`。
+
 > 給 **你（人）** 在交給客戶前跑一次的精簡清單，不是給 Haiku 操盤的詳細壓測（那份在
 > 壓測-recipe-library-2026-06-07.md）。順序照客戶真實旅程。**任一項 ❌ = 不能交付。**
 > 過關標準都是客觀證據（HTTP 2xx / D1 數字 / 檔案存在），禁口頭過關。

system-dev/docs/5-records/test-reports/壓測-recipe-library-2026-06-07.md

@@ -1,5 +1,8 @@
 # 壓測 Test Case — Recipe 公庫/私庫機制 + UUID（2026-06-07 deploy 後）
 
+> ⚠️ 歷史記錄。文中 credential 相關步驟依據的舊自管金鑰機制已於 2026-07-20 完全移除，
+> **勿照本文操作**；現行做法見 `.claude/rules/01-tech-stack.md`。
+
 > 對象：本次上線的 kbdb-base §7.5（公庫/私庫雙向、UUID 身份、市場數據）+ 回歸。
 >
 > **操盤模型：全程 Haiku。Haiku 能搞定是「設計目標」不只是壓測手段（richblack 2026-06-07）。**