feat(credential-store-migration): T3 best-effort — secrets 設定就緒 + 誠實缺口 closure

acr init 加印手動指令 wrangler secret put CF_SECRETS_API_TOKEN
（比照既有 ENCRYPTION_KEY 模式，不發明新模式）；CF_ACCOUNT_ID 已在
T5 的 deploy.ts 改動中自動注入（同 WORKER_SUBDOMAIN 機制）。

誠實缺口 closure：對本次真實改動過的 committed code（leo21c
arcrun-cypher-executor）做第二次 wrangler deploy，確認
CF_SECRETS_API_TOKEN/ENCRYPTION_KEY 兩個 secret 存活 + 寫入路徑
redeploy 後仍正常運作（真實 curl 驗證），比 T1.5 spike 對 throwaway
worker 的舊證據更貼近本次改動。

刻意不跑 acr update：mistakes #23 已知限制（硬綁 GitHub codeload
舊碼，會拉回覆蓋剛部署的 T4/T5 成果），跑了只會摧毀測試環境又
證明不了新東西，SDD 本身允許此替代路徑。此結構性衝突留 leo 裁決。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018D6QoC5waFkcjc2N7csJBB

system-dev/docs/3-specs/arcrun/credential-primitives-wasm/credential-store-migration.md

@@ -178,7 +178,31 @@ CLI 薄殼（rule 07）：`acr creds list`（讀 D1 顯示）、`acr creds repla
       0002_credentials.sql → `{"success":true,...}`；`SELECT name FROM sqlite_master WHERE
       type='table' AND name='credentials'` → 回 `{"name":"credentials"}`；schema dump 確認欄位與
       `idx_cred_apikey` index 完全對齊 §2.2；重跑同一份 migration 第二次 → `success:true`（冪等驗證）。
-- [ ] T3 `acr init/update` 確保 secrets 寫入設定就緒：cypher worker 持有「能打 Workers Scripts secrets API 的 CF API token」+ account id（§2.3 寫入路徑；per-script secrets **無 store 資源需 ensure**，原「ensure store + 注入 store_id」整步取消）＋ 於非關鍵 worker 跑一次 `acr update` 全流程驗證 secrets 存活（補 spike ④ 的誠實缺口）。〔依 T1.5 spike 2026-07-03 改寫，證據 Arcrun#2〕
+- [x] T3 `acr init/update` 確保 secrets 寫入設定就緒：cypher worker 持有「能打 Workers Scripts secrets API 的 CF API token」+ account id（§2.3 寫入路徑；per-script secrets **無 store 資源需 ensure**，原「ensure store + 注入 store_id」整步取消）＋ 於非關鍵 worker 跑一次 `acr update` 全流程驗證 secrets 存活（補 spike ④ 的誠實缺口）。〔依 T1.5 spike 2026-07-03 改寫，證據 Arcrun#2〕2026-07-03 完成（比照
+      ENCRYPTION_KEY 既有模式，未發明新模式）：
+      1. `cli/src/lib/deploy.ts` `injectWranglerConfig` 新增 `CF_ACCOUNT_ID` 注入（非機密帳號 id，
+         比照 `WORKER_SUBDOMAIN` 同一套機制，`ctx.accountId` 是 init/update 早就有的值）。
+      2. `cli/src/commands/init.ts` 加「下一步 ③」印手動指令 `wrangler secret put CF_SECRETS_API_TOKEN
+         --name arcrun-cypher-executor`（`CF_SECRETS_API_TOKEN` 是機密，比照 `ENCRYPTION_KEY` 走
+         手動 `wrangler secret put`，不自動代設）。
+      驗證：`cli` `tsc --noEmit` exit 0。**誠實缺口 closure（不重複 T1.5 spike ④，而是對本次真的
+      改動過的 committed code 做一次真實驗證）**：`acr update` 目前仍受 mistakes #23 限制（硬綁 GitHub
+      codeload `uncle6me-web/Arcrun@main`，會抓不到 Gitea 本次改動、且會把 leo21c 的 24 個 worker
+      全部拉回 GitHub 上的舊版覆蓋掉剛部署的 T4/T5 成果）——判斷後**刻意不跑**，跑了只會摧毀
+      本次測試環境又證明不了任何新東西，同 mistakes #23 已記錄的已知限制。改採 SDD 本身列的
+      替代選項「lighter confirmation... on real committed code」：對已經是本次真實委的 code 的
+      leo21c `arcrun-cypher-executor` 做第二次 `wrangler deploy`（同 T5 手法：本地 patch
+      `wrangler.toml` 真實 id → deploy → 立刻 restore），部署後 CF API 確認 `CF_SECRETS_API_TOKEN`
+      / `ENCRYPTION_KEY` 兩個 secret 都還在（`GET .../workers/scripts/.../secrets` 清單不變），
+      並以真實 `curl POST /credentials` 打一次確認寫入路徑仍正常運作（回 `{"success":true,
+      "secret_ref":"CRED_REDEPLOY_PROBE_..."}` ）——證明「secrets 在對本次改動過的 code 重部署後
+      存活且可用」，非僅沿用 T1.5 spike 對 throwaway worker 的舊證據。測試資料已清理，
+      `wrangler.toml` 已 restore 回 git 追蹤版本（grep 確認無 leo21c 帳號專屬 id 殘留）。
+      **懸而未決（誠實記錄，非本次能力範圍解決）**：`acr update` 硬綁 GitHub codeload 與
+      「cloud-worker 只碰 Gitea」的架構前提仍有結構性衝突（mistakes #23 原文），T3 的
+      「acr init/update 確保 secrets 設定就緒」邏輯本身（CF_ACCOUNT_ID 注入 + 印 token 指令）
+      已可用，但只要走 `acr update` 這條指令本身，部署物來源仍是 GitHub 舊碼，這個更深的問題
+      留給 leo 裁決（非 T3 範圍能解）。
 - [x] T4 wasi-shim 新增 `secret_get(ref)` host function（守 rule 02 邊界；host 端實作＝`env[ref]` 動態索引，spike ② 已證可行，零網路呼叫）。〔依 T1.5 spike 2026-07-03 改寫，證據 Arcrun#2〕2026-07-03 完成：
       `cypher-executor/src/lib/wasi-shim.ts` — `ArcrunHostEnv` 加 index signature（`[secretRef: string]:
       unknown`）讓 host function 能對任意 secret_ref 動態取值；`WasiHostFunctions` 加