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/wiki/cards/decisions/00-INDEX.md

@@ -23,7 +23,6 @@
 
 ## credential / recipe
 
-- [[多worker-ENCRYPTION_KEY同步]] — 各 Worker secret put 同份 key，漂移→解密失敗表現為 401/403
 - [[Recipe-UUID市場模型]] — canonical+uuid+author 多維身份，per-uuid 市場數據
 
 ## kbdb

system-dev/wiki/cards/decisions/多worker-ENCRYPTION_KEY同步.md

@@ -1,35 +0,0 @@
----
-tags: [credential, 部署, 架構決策, 踩坑]
-gloss: 多個 Worker（auth primitive + cypher-executor）共享 ENCRYPTION_KEY，用 wrangler secret put 手動設進各 Worker secret store，不用 KV。
----
-# 多 Worker ENCRYPTION_KEY 同步
-
-← [[decisions/00-INDEX]]
-
-**來源**：`system-dev/wiki/decisions-summary.md`（多 Worker ENCRYPTION_KEY 同步）、`.claude/rules/01-tech-stack.md` 加解密規範
-**最後更新**：2026-06-27
-
-## 摘要
-Auth static_key / Auth service_account / cypher-executor 三個 Worker 都需 ENCRYPTION_KEY 來解密 credential。用各 Worker 的 secret store（非環境變數）存放；初期化時 `acr init` 生成一份 key，用 `wrangler secret put ENCRYPTION_KEY` 各設一次。
-
-## 重點
-- **Secret 存儲位置**：各 Worker 的 secret store（Cloudflare 原生機制），不是環境變數、不是 KV。環境變數會洩漏到日誌；KV 的 list 操作可能外洩。
-- **初始化流程**：`acr init` 生成一份 32 字節隨機 key → 印出一次 → 用戶自己跑 `wrangler secret put ENCRYPTION_KEY --path <path>` 分別設進三個 Worker。
-- **冪等性問題**：目前 `acr init` 多跑幾次會生成不同 key（不冪等）。長期應改成「init 檢查現有 config → 若存在 key 則重用舊的、否則生成新的」。
-- **漂移陷阱**：若某個 Worker 的 key 遺漏或與其他 Worker 不同 → credential 解密失敗 → 表現為 401/403（用戶困惑，難debug）。
-- **驗證方法**：init 完成後做一個 test workflow 打一個認證過的 API（如 gmail），確認三個 Worker 的 key 一致。
-
-## 實體
-- **ENCRYPTION_KEY**（加密密鑰）— 32 字節 AES-GCM 密鑰，用來解密用戶的 credential。
-- **Secret store**（Cloudflare 密鑰存儲）— Worker 的原生機制，用 `wrangler secret put` 設置、runtime 讀取，內容不外洩。
-- **密鑰漂移**（key drift）— 多個 Worker 持有不同版本的 ENCRYPTION_KEY，導致某些 Worker 解密失敗。
-- **冪等性**（idempotency）— `acr init` 多次運行應產生同一結果（目前不達成）。
-- **解密失敗**（decryption failure）— Worker 因 key 不匹配無法解密 credential，表現為 401/403 錯誤。
-
-## 關聯
-### 內文知識關係
-- ENCRYPTION_KEY >> 分散存儲於 >> Secret store
-- 密鑰漂移 >> 導致 >> 解密失敗
-- 冪等性 >> 缺乏時 >> 重跑 init 造成 key 不一致
-### 卡片關係
-- （相關 memory：`encryption-key-drift-trap` — 解密失敗先比 key 指紋；屬 auto-memory 非 card）