[Bug] Windows 原生文件夹选择器把路径在"低字节为 0 的汉字"处截断（如"xx项目开发"变成"xx项目"）

[dandaogc]

我很高兴发现了dsh的一个bug，天啊，我竟然也参与了一把

现象 文件夹名里含有 UTF-16LE 低字节为 0 的汉字（如"开"U+5F00、"万"U+4E07、"不"U+4E0D、"中"U+4E2D、"主"U+4E3B）时，选择该文件夹后返回的路径会在这个字处被截断，导致新建工作区报错 ENOENT。这个问题在中文环境下非常容易遇到——很多常用汉字都会触发。

环境

DSH 0.1.0-rc.7
Windows Server 2022 (10.0.20348)
Node v24.14.1
Web 界面（Windows 原生"Select Workspace Directory"对话框）
复现步骤

新建文件夹 E:\xx项目开发（含"开"U+5F00）。
Web 界面左侧点"新建工作区"，弹出 Windows 原生文件夹选择对话框。
鼠标选中 E:\xx项目开发，点"选择文件夹"。
报错：workspace create failed: workspace-invalid-path: cannot create a workspace at "E:\xx项目": ENOENT: no such file or directory, realpath 'E:\xx项目'
末尾"开发"两个字被剥掉。对照组：xx办公区（办/公/区低字节均非 0）和 xx测试测试 都能正常创建。对话框里显示的是完整文件夹名，截断发生在从 COM 读回路径时。

根因 在 @deepseek-ai/dsh-host-directory-picker-native 的 lib/worker.cjs 中，readUtf16 函数（源文件应为 packages/host/directory-picker-native/src/win32-dialog-bindings.ts）：

function readUtf16(koffi, address) {
const bytes = Buffer.from(koffi.view(address, 32768));
let end = 0;
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2; // BUG: 只检查低字节
return bytes.toString("utf16le", 0, end);
}
它按 2 字节步进查找字符串结尾时，只判断每个 UTF-16 单元的低字节是否为 0。"开"（U+5F00）的 UTF-16LE 编码是 00 5F——低字节恰为 0，被误判为字符串结束，其后的"发"等字符被静默丢弃。

修复

while (end + 1 < bytes.length && (bytes[end] !== 0 || bytes[end + 1] !== 0)) end += 2;
验证 本地打补丁后实测：worker 返回完整路径 E:\xx测试测试开发（11 个字符，含 U+5F00 U+53D1）；补丁前返回 E:\xx测试测试（9 个字符）。已通过独立启动同一个 worker 复测确认。

影响范围 所有文件夹名中含低字节为 0 的汉字的目录都会中招，例如"开/万/不/中/下/主/久/两/且"等——项目开发、开发中、万维网 这类常见目录名都会触发。