[Bug] 百智云「浏览器登录」在装了夸克浏览器的机器上必挂：候选顺序选中夸克，而夸克的 CDP 目标会在 ~10s 内消失 #7

版本：magpie-monkeycode 0.2.44（5dfc366，即 bun.lock 里钉住的那个提交）
宿主：magpie 0.1.3598 · Windows 11 26100 · Node 22（bun 宿主）
涉及文件：src/browser-login.mjs、src/session-login.mjs

现象

点「百智云 → 浏览器登录」，夸克窗口确实弹出来了、也能打开 https://baizhi.cloud/console/，但约 10 秒后 magpie 报错面板显示：

登录未完成
the sign-in failed: 受控浏览器窗口被关掉了（或被系统拦下没能启动）

窗口还开着，用户并没有关它。点「重试」每次都是同样结果。

根因（两层，叠加起来必挂）

1. findBrowser() 选中了夸克，而不是用户的默认浏览器

WIN_EXES（src/browser-login.mjs:24-40）把 msedge.exe 放在最后一位，Quark.exe 在它前面：

chrome.exe → 360… → QQBrowser → Brave → … → UCBrowser.exe → Quark.exe → msedge.exe

browserCandidates() 先按这个顺序查注册表 App Paths，命中的全部排在硬编码路径之前。本机实测：

夸克注册了 App Paths，于是候选表第 0 位就是它，findBrowser() 取第一个存在的 → 夸克。Edge 明明可用、也确实是系统默认浏览器，却被排在后面——代码完全没有读 UserChoice。

2. 夸克不能胜任这条 CDP 登录路（这才是真正致命的）

夸克能开调试端口（/json/version 正常返回 Chrome/144.0.7559.86），所以 openControlledBrowser() 的握手会成功。问题在后面：夸克会把自己的内部页持续注入 /json/list，并且把插件已经连上的那个 page 目标销毁掉。

按 target id 精确观察（登录页用 https://baizhi.cloud/console/）：

插件连上: id=6AEB4B3CA9B8E34917EF9A3A24A8B5A6  url=https://baizhi.cloud/console/
   t+  1s  我的目标存活=true   cookie=OK(1)
   t+  2s  我的目标存活=true   cookie=OK(3)      ← 页面跳到 /sign-in?redirect=%2Fc
   t+  9s  我的目标存活=true   cookie=OK(6)
   t+ 10s  readyState=3        cookie=FAIL(CDP 命令超时 Network.enable)
>>> 已连接 WS 断开时刻: 9.6s

Edge 同样的脚本跑 28 秒，目标一直存活、cookie 稳定读到 20 枚：

   t+  1s  我的目标存活=true  cookie=OK(1)
   ...
   t+ 28s  我的目标存活=true  cookie=OK(20)      ← 全程稳定

用 about:blank 起页时还能看到目标列表被内部页淹没的过程：

### Quark @ about:blank   起页时 page 目标数: 1
  6s 后: NEW:uccd://cloud.quark/clouddrive/renderer/index.html
         NEW:uccd://qwen.voice-agent/.../renderer/toast
         NEW:uccd://qwen.voice-agent/.../renderer/index
         NEW:uccd://qwen.voice-agent/.../renderer/index
         SAME:about:blank

于是 startBrowserLogin() 的存活检查（session-login.mjs:306）：

const closed = () => handle.ws.readyState !== 1

在 ~10 秒变成真，抛出「受控浏览器窗口被关掉了」。用户看到的是"窗口被关掉"，实际是 CDP 目标被夸克回收了——这条错误消息在这个场景下是误导。

还有一个独立的坑：/json/list 里第一个 page 目标在夸克上不一定是登录页（上面那次 6 秒后首位就变成 uccd://qwen.voice-agent/…）。openControlledBrowser() 取的是 pages.find(...) 的第一个，所以即便 WS 不断，也可能连到一个内部页、永远读不到 baizhi.cloud 的 cookie。

复现

Windows + 装了夸克（夸克会主动注册 App Paths）+ 没装 Chrome。下面这段直接调插件自己的代码，不需要 magpie：

import { startBrowserLogin } from "magpie-monkeycode/src/session-login.mjs"
import { findBrowser } from "magpie-monkeycode/src/browser-login.mjs"

console.log(findBrowser())   // → { name: "Quark", path: "F:\\Tools\\Quark\\quark.exe" }

const h = await startBrowserLogin({
  url: "https://baizhi.cloud/console/",
  cookieNames: ["__never_matches__"],
  accept: async () => false,
  timeoutMs: 45_000,
})
try { await h.wait() } catch (e) { console.log(e.message) }
// 夸克：约 10s 后 → "受控浏览器窗口被关掉了（或被系统拦下没能启动）"
// 对比：同一份代码传 { browser: { name:"Edge", path:"…\msedge.exe" } } → 撑满 45s 才 "登录超时"

想只看目标churn，不跑插件逻辑的话：起浏览器时带 --remote-debugging-port，轮询 http://127.0.0.1:<port>/json/list，盯住你连上的那个 id 什么时候消失。

期望

findBrowser() 优先用系统默认浏览器（读 UrlAssociations\http\UserChoice\ProgId → Classes\<ProgId>\shell\open\command 取 exe），前提是它在「CDP 稳定白名单」里（chrome / msedge / chromium / brave / vivaldi / opera）；不在白名单或解析失败，才退回现在的候选顺序。

建议的修法（按性价比排序）

1. 默认浏览器优先 + CDP 稳定白名单（上面那条）。夸克这类浏览器带自己的内部页体系，CDP 目标生命周期不受外部控制，不适合做受控登录载体——建议把它们从 WIN_EXES 里摘掉，或明确降级为"白名单全不可用时的最后兜底"。
2. 按 URL 挑目标，不要取第一个 page：pages.find((p) => p.type === "page" && p.url.startsWith(登录页 origin))，找不到再退回第一个。
3. 存活检查别只看 ws.readyState：目标churn 时 WS 可能还活着但目标已没了（我这边两种形态都遇到了）。可以在轮询里重新按 URL 找回目标、必要时重连，或者把"目标消失"和"窗口被关"分成两条不同的错误消息——现在这条把用户往错误的方向引（他会以为自己不小心关了窗口）。
4. 一个逃生阀：MAGPIE_BROWSER=<exe 绝对路径> 之类，让用户能显式指定，不必改源码。

我本机打的临时补丁（供参考，不一定合用）

在 browser-login.mjs 里加了 systemDefaultBrowser()（读 UserChoice → open command → 抽 exe → 校验白名单），browserCandidates() 多收一个 defaultBrowser 参数插到最前，findBrowser() 支持 MAGPIE_BROWSER / MAGPIE_BROWSER_PREFER_DEFAULT=0。效果：

systemDefaultBrowser = {"name":"msedge","path":"C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe"}
findBrowser()        = {"name":"msedge", ...}

tests/browser-login.test.mjs 4 项仍全绿（默认参数下候选顺序不变，测试注入 lookup / exists 也不受影响），端到端跑 startBrowserLogin() 从 ~10s 报错变成撑满超时。只是这个补丁会被下一次插件更新覆盖掉，所以还是希望上游收一下。

另外顺带一个小问题：registryAppPath() 里的 execFileSync("reg", …) 没重定向 stderr，查不到键时 ERROR: The system was unable to find the specified registry key or value. 会进 magpie 的 app.log（一次登录刷几十行）。加个 stdio: ["ignore","pipe","ignore"] 就干净了。