fix(windows): spawn .cmd shims through the interpreter and report owned exit codes

[Patodo]

让 Windows 上的本地开发流程真正可用。三条缺陷都是我在同一台机器上跑完整流程时定位并验证的。

① localapp init 装不上依赖

const child = spawn("npm", ["install"], { … });

Node 在 Windows 上不能 spawn .cmd 垫片（CVE-2024-27980 之后必须经 shell），PATH 上只有 npm.cmd/npm.ps1，于是 ENOENT → dependency_install_failed，并且失败后把刚建的项目回滚删除。

新增 src/process/command-invocation.ts：裸命令名交给命令解释器（解释器是绝对路径，并通过 PATHEXT 解析垫片）；带路径的调用保持不变。

② localapp dev 起不来项目脚本

dev 的 runner 把裸 npm.cmd 交给受控包装层，而包装层只接受绝对可执行路径，脚本永远启动不了。

• TS 侧：按 PATH + PATHEXT 把垫片解析成绝对路径。这里有个坑值得记下：npm 会在旁边装一个无扩展名的 POSIX 脚本 npm，先试裸名就会拿到它，解释器执行失败返回 1——所以必须先按 PATHEXT 解析（测试里加了无扩展名诱饵钉住）。
• Rust 侧：job_owner 遇到 .cmd/.bat 目标时自己起命令解释器并构造命令行。这是唯一能控制 cmd 解析的那一行引号的层——从 TS 侧传 /d /s /c 给包装层不行，因为它会对每个 argv 元素重新加引号，解释器随后起的是交互式会话。

③ 装应用时服务端 EPERM fsync

app-installer.ts 保留包那一步用只读句柄打开副本后调 handle.sync()；Windows 的 FlushFileBuffers 需要可写句柄，于是每次都 APP_INSTALL_FAILED: EPERM fsync。同文件里早已有 syncFile() 承担这条规则（"r+" + 容忍纯访问类失败），改用它。

（定位过程：fs.fsyncSync 打点抓不到，换成连 FileHandle.prototype.sync 一起打点才确认——这也说明 61f5c8a 那批加固漏掉的正是这种 FileHandle 形态。）

④ 模板自带测试在 Windows 上必然失败

localapp check 在任何新脚手架工程上都是红的，因为模板测试有两条断言直接比较多行源码文本，而 Windows 检出与 Windows 侧的模板同步都是 CRLF，toContain("...\n...") 永远不匹配。这独立地挡住了 dev（dev 会跑同一套检查）。在测试的读取函数里统一换行。

端到端验证（Windows 11 26200，用打包产物，未加任何垫片）

localapp init app1        -> {"created":"app1"}，装下 570 个包
localapp check            -> "success":true，7/7 阶段全过
localapp dev              -> App URL: http://127.0.0.1:61275/
                             Local Server: http://127.0.0.1:49860
$ curl <App URL>          -> 200，返回 Vite dev shell
$ curl <Server>/health    -> {"status":"ok"}

测试

• tests/command-invocation.test.ts：6 例（含无扩展名诱饵、PATHEXT 顺序、路径不被改写）
• native-adapter.node-test.mjs：源码断言钉住退出码传播与 .cmd/.bat 包装
• tsc --noEmit 通过；test:public-source 通过

未包含

localapp server restart 会报 ipc_response_invalid 但实际重启成功——原因是控制处理器期限 5s 短于 daemon 自身的 readiness 预算 15s，连接在写响应前被销毁。与本次改动无关，需要单独修。