Leo
f903a3f53f
t176 daemon：LLM 設定移回地端＋托盤單一實例（leo 08-03 架構翻案）
leo 回報 Windows daemon 三症狀，查完 ①③ 同根，根在「雲端控制地端」這個設計。
【①③ 真兇】雲端 extractor_config 是**全租戶共用一把 KV**
（arcrun:portal.ts:43 portalTenant = worker 層級變數，不分用戶），
任一處設了 claude → 所有人的 daemon 都收到 claude。沒裝 Claude Code 的機器
FindClaudeBin 失敗 → 每檔萃取 failed、一張卡都沒建；想去 portal 改回 gemini，
checkbox 卻恆 disabled（claude_available 恆 false，因 daemon 從未實作
report-capabilities 回報 → daemon_caps KV 永遠空）⇒ 用戶自己解不開。
awindhon 實證：雲端同步成功、Gemini key 有效、零張卡，config.json extractor="claude"。
【leo 裁示】「地端要用什麼模型就在 daemon 上輸入 API Key 設置，而不是雲端設置後
控制地端」「地端先限制 Gemini API Key 配合客戶要求」「雲端就是 Workers AI」。
本次（daemon 端）：
- addOrUpdateAccount 不再接受雲端下發的 extractor/gemini_api_key/llm_model，
只收連線欄位。t126「每帳號一份萃取設定」照舊保留——t126 修的是「存在哪一層」，
本次改的是「值從哪來」，兩者正交。
- 托盤新增「AI 設定…」：使用者自己填 Gemini API Key，寫本地 config 後立即生效。
- 萃取一律走 gemini：殘留的 extractor:"claude" 正規化為 gemma；claude 路退役。
⚠️ 這不是「自動偵測有無 claude」（leo 07-27 已否決的 B 案），是整條路先不支援。
- 清掉隨之死亡的 claude_bin 回寫（死代碼＝錯誤的環境信號）。
- 托盤單一實例（症狀②）：pidfile + 跨平台 processAlive。
mac 之前不多開是借 macOS Launch Services 的巧合，Windows 沒有該層 ⇒ 每點一次多一個 icon。
Unix 用 signal 0（EPERM 也算活著，測試抓到的實際 bug）／Windows 用 OpenProcess+ExitCode。
測試：collector 全綠、tray 全綠。5 個原本用 claude stub 的測試改走**真實 gemma 路**
（httptest 替身注入 gemmaBaseURL），不是改斷言充綠；t126②③ 兩案翻轉成
「雲端下發一律被忽略」的回歸守衛；新增 4 案 single-instance。
未送達：本 commit 只到 code，尚未打包出貨；雲端側（刪 portal AI 設定區塊、
extractor 下發、admin/extractor）未動，待部署授權。CP rag-beta 步驟仍為 ◐。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>