jkooe
1471708f35
ci: 新增 Windows 控制台安装包构建（x64 + arm64 双架构）
在此之前，控制台的 Windows 侧只被验证到「prepare:node + 自举」（见 windows-e2e），
**从未真跑过 tauri build**。而 Rust 里那些 cfg!(windows) 分支（taskkill 收进程树、
PowerShell 计划任务、node.exe 路径解析）在 macOS 上只被类型检查、
从未被编译成 Windows 目标，更没有产物级验证 —— 本工作流是它们的第一道真闸。
为什么必须双架构
----------------
被控端发布包出过「arm64 包里装的是 x64 node.exe」的事故：在 ARM Windows 上
**能 listen、但 TLS 握手不完成**，且 macOS 侧 100% 复现不出。
控制台同理 —— 它内含 node 运行时，且要用它**托起本机被控端**（即 TLS 服务端）。
故 x64 / arm64 必须各出一套。
为什么用原生 ARM runner 而不是交叉编译
------------------------------------
`windows-11-arm` 是 GitHub 的 ARM64 Windows runner（公共仓库免费，本仓库为 public），
在它上面 arm64 是**原生构建**。若改走 x64 机器交叉编译，需要 VS 的 ARM64 工具链，
且 prepare-console.mjs 的自检要**真执行** node.exe（x64 机器跑不了 arm64 二进制），
会逼着引入「跳过自检」这类削弱验证的开关 —— 宁可等原生 runner。
两条断言是必需项，不是顺手检查
----------------------------
1. **构建机架构 ⇄ 目标架构**：ARM runner 镜像里确实存在 x64 模拟的组件
（社区实测 python 即为 AMD64）。一旦 Node 也是模拟版，process.arch 会是 x64
→ 把 x64 的 node.exe 打进 arm64 安装包 → 真机上能启动、TLS 握手不完成，而 CI 全绿。
2. **随包 node.exe 的 PE Machine**：与 pack.mjs 的双架构校验同源思路 ——
不只看「脚本跑完了」，而是直接读最终要打进那个包的二进制头。
中间逻辑再自洽，也可能因上游给了错架构的二进制而产出错包。
另断言安装包体积 > 50MB：含 Node 运行时（约 80MB），体积过小意味着运行时没打进去
—— 那种包能装、但一启动就找不到 node。
产物：x64 出 msi + nsis（企业批量部署 + 普通双击各一），arm64 只出 nsis
（WiX 的 arm64 MSI 支持面较窄，不值得为它引入不确定性）。
2026-10-11 23:25:16 +08:00
..
2026-10-11 23:25:16 +08:00
2026-10-11 11:42:14 +08:00
2026-10-11 11:42:14 +08:00