[bug] Win32 原生目录选择器在 U+XX00（如「开」）处截断 UTF-16 路径 — 附可 cherry-pick 修复

[ericcaiwx-star]

摘要 / Summary

Win32 原生文件夹选择器把 UTF-16LE 路径扫成 JS 字符串时，把「低字节为 0」的 BMP 字符误判成 NUL，路径在该字符处被截断。选 C:\Users\XIAOPAN\Desktop\安卓开发 会得到不存在的 ...\安卓，工作区创建失败。

This is the same defect reported in #563. A tested one-commit fix is ready to cherry-pick.

复现 / Repro

1. Windows 上用 GUI「添加工作区」选含「开」(U+5F00) 的目录，例如 C:\Users\XIAOPAN\Desktop\安卓开发。
2. 实际：workspace-invalid-path: cannot create a workspace at "...\安卓": ENOENT。
3. 期望：返回完整路径。

根因 / Root cause

packages/host/directory-picker-native/src/win32-dialog-bindings.ts 的 readUtf16 用 bytes[end] !== 0 找终止符。UTF-16LE 的真正 NUL 是 两个 零字节。开 = U+5F00 → 字节 00 5F，低字节为 0，扫描提前结束。

任何 U+XX00 码元都会从该处截断，不限于「开」。

修复 / Fix (cherry-pick ready)

官方暂不收外部 PR，补丁在 fork 上：

• 分支：https://github.com/ericcaiwx-star/deepseek-harness/tree/fix/win32-utf16-nul-truncation
• commit：c8aac14703 — fix(directory-picker-native): stop truncating Win32 UTF-16 paths at U+XX00
• 对比：master...ericcaiwx-star:deepseek-harness:fix/win32-utf16-nul-truncation

终止条件改为「两个字节都为 0」。单测用假 COM 世界覆盖 安卓开发（U+5F00），不依赖真 Windows。

验收 / Acceptance

pnpm exec vitest run packages/host/directory-picker-native/tests/win32-dialog-bindings.spec.ts 通过。含 U+XX00 的路径不再被截断。

[zhou256bug]

我是外面看这条的开发者，对照了 master 上的 readUtf16 和 fork 分支 fix/win32-utf16-nul-truncation 的 diff。

根因说得通：UTF-16LE 的终止符是两个零字节，按 bytes[end] !== 0 扫会把 U+XX00（「开」这类低字节为 0 的 BMP 码元）当成 NUL。这不是单个汉字的问题。补丁改成双字节都为 0，范围也克制，假 COM 单测能钉住这个码元。

一个小建议：复现和夹具路径尽量用合成目录名，不要带真实用户目录。这条看起来就是独立的编码/FFI 修复，不像要动整个 picker。

[ericcaiwx-star]

谢谢对照 readUtf16。

单测走的是假 COM 缓冲里的合成 UTF-16LE（含 U+5F00「开」），没有真实用户目录。复现描述里的「开」也只是这个码元的例子。picker 本身没动。

这条按独立编码/FFI 修复保持，不再扩范围。

[zylos-luna]

Confirmed against master: readUtf16 scans with bytes[end] !== 0, and since the buffer is UTF-16LE, any BMP code unit of the form U+XX00 puts a zero at the even (low-byte) offset — the scan terminates mid-string exactly as described, not just for 开. The two-byte terminator check is the precise fix: end only ever lands on code-unit boundaries, and U+0000 is the only unit with both bytes zero, so there is no way this change under- or over-terminates. The fake-COM test pinning U+5F00 makes the regression checkable without a Windows runner, which is the right shape for this package.

[Xilink-Lin]

readUtf16 用 bytes[end] !== 0 扫 UTF-16LE，把 U+XX00（开 = 00 5F）当成 NUL。这是教科书级 FFI 编码错误，不是「某个汉字」的问题。改成双字节都为 0 才停，语义正好覆盖 U+0000，不会欠终止也不会过终止。假 COM 夹具钉住 U+5F00，不依赖 Windows runner，形状对。

小建议：夹具路径仍是 C:\Users\XIAOPAN\Desktop\安卓开发。功能上无所谓（假 COM），公开仓库里换成合成名更干净。koffi.view(..., 32768) 的硬上限是原问题，别塞进这条。

[ericcaiwx-star]

夹具路径已换成合成名 C:\fixture\安卓开发，仍钉住 U+5F00。koffi.view 上限不进这条。

commit：e1d6265cb9（同一分支 fix/win32-utf16-nul-truncation）。