fix(windows): pair remote debugging with a managed CDP profile (#235)

[Fei-Away]

这是不是 bug —— 有一半不需要 Windows 机器就能确认

出厂路径里没有任何调用方传过 -ProfilePath：

$ grep -rn 'ProfilePath' windows/ --include='*.ps1' --include='*.mjs' | grep -v start-dream-skin.ps1
(无输出)

所以这个分支在每一次真实启动中都为假：

if ($ProfilePath) {                        # ← 恒为 false
  $arguments += "--user-data-dir=$ProfilePath"
}

--user-data-dir 从来没有被发出去过。 而 Chromium 136 起会忽略指向默认数据目录的 --remote-debugging-port。两者相乘 = 当前 Codex 上调试端点根本不开、injector 连不上、皮肤完全不生效。这是代码事实，不需要 Windows 主机就能确认。

需要实机确认的只有第二半：「补上受管 --user-data-dir 之后 CDP 就恢复」。依据是 #363 报告者在 Store Codex 26.803.10989.0 / Chromium 151.0.7922.76 上的对照探测——只传端口没有端点；同一个签名可执行文件加上隔离 --user-data-dir 后，回环 Browser WebSocket、app://-/index.html renderer、真实主题注入验证全部通过。

合并前的复核记录

• 只有一条 Codex 启动路径。 grep -rn "remote-debugging" windows/scripts/ 除 start-dream-skin.ps1 外只命中 common-windows.ps1 里的 Get-DreamSkinCodexDebugArgumentStatus，那是读命令行做判定、不是启动。所以不存在「某条路径带受管 profile、另一条不带」的分裂风险。
• 没有消费者把 state.profilePath 当作"用户覆盖"标记。 该字段现在总会被填上，但 grep 确认无人据此分支。
• Ensure-DreamSkinManagedDirectory -Path $ProfilePath -Root $StateRoot：cdp-profile 直接位于 StateRoot 之下，包含性检查成立。
• 不修改 WindowsApps、不改官方包或签名、不接管 ACL。

怎么测（不用 clone 分支）

本 PR 的 CI 会直接产出可安装的 Setup.exe：

1. 打开本 PR 的 Checks → Windows (Windows PowerShell 5.1)
2. 页面底部 Artifacts 下载 CodexDreamSkin-setup（约 23.7 MB）
3. 解压得到 CodexDreamSkin-Setup-v1.5.16.exe，正常安装

（这个能力是 #387 刚加的：此前 CI 只是编译 Setup.exe 做构建检查然后丢掉，只有 macOS 会上传 DMG。所以以前 Windows 侧的修复根本没法交给报告者验证。）

请测试者确认三件事：

1. 用 Dream Skin 快捷方式启动 Codex，皮肤是否正常出现（核心）
2. %LOCALAPPDATA%\CodexDreamSkin\cdp-profile 是否被创建
3. 首次启动是否需要在 Codex 里重新登录一次 —— 这是本方案的已知代价，受管 profile 与官方 profile 隔离。登录一次后应持久保留，请特别确认第二次启动不再要求登录。

合并不等于发版

macos/VERSION 未变（仍是 1.5.16），release workflow 的 guard 会判定 version_unchanged=true → should_release=false。合进 main 不会推给任何用户，要等到有人 bump 版本号切 v1.5.17 才会真正发布。所以实机验证仍可在发版前完成。

已从 #387 拆出并 rebase 到 main，现在是对 main 的单 commit / 6 文件。