[BUG] Windows 目录选择器读取路径被截断（readUtf16 只检查低字节），含"一"等汉字的路径创建工作区失败 ENOENT

[za15842]

Summary / 概述

On Windows, when adding a workspace through the native folder picker, the picked
path is read by readUtf16() in
packages/dsh-host-directory-picker-native (lib/worker.cjs). Its end-of-string
test only checks the low byte of each UTF-16LE code unit:

// buggy
while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;

For any CJK character whose UTF-16LE encoding has a low byte of 0x00 — e.g.
"一" (U+4E00, encoded 00 4E) — the loop stops early and the path is
truncated at that character. fs.realpath then fails with ENOENT and the
workspace cannot be created ("file does not exist", path shown truncated).

中文：Windows 上通过原生文件夹对话框添加工作区时，readUtf16() 判断字符串结尾
只检查 UTF-16LE 的低字节。路径中含有"一"（U+4E00，编码 00 4E，低字节为
0x00）等汉字时，循环提前终止，路径被截断，fs.realpath 报 ENOENT，工作区创建
失败，错误信息里路径也显示为截断后的样子。

Environment / 环境

• DSH version: 0.1.1-rc.2 (also reproduced reasoning on 0.1.1-rc.2 layout)
• OS: Windows (Chinese locale, code page 936)
• Backend in use: native directory picker
  (@deepseek-ai/dsh-host-directory-picker-native) — auto-resolved when
  bound to 127.0.0.1 on win32 without SSH.
• Repo file: packages/dsh-host-directory-picker-native/src/types/win32-dialog-bindings.ts
  (built output lib/worker.cjs, function readUtf16, line ~21-26).

Steps to reproduce / 复现步骤

1. On Windows, run dsh web (bound to 127.0.0.1), open the browser UI.
2. Create a real directory whose path contains a CJK char with UTF-16LE low
   byte 0x00, e.g. D:\repro\检测工程参数是否一致
   (the 9th char "一" is U+4E00).
3. Click "Add workspace" → native Windows folder picker → select that directory.
4. Observe failure:

workspace create failed: workspace-invalid-path: cannot create a workspace at "D:\repro\检测工程参数是否": ENOENT: no such file or directory, realpath 'D:\repro\检测工程参数是否

The path is truncated: 检测工程参数是否一致 (10 chars) became
检测工程参数是否 (8 chars) — "一致" is lost. Any path containing "一" (U+4E00)
or similar (low byte 0x00) triggers this.

Root cause / 根因

readUtf16 scans a UTF-16LE buffer for the NUL terminator but tests only
bytes[end] !== 0 (the low byte). UTF-16LE encodes U+4E00 as bytes 00 4E;
the low byte 0x00 is mistaken for the string terminator, so scanning stops
mid-character and the returned path is truncated.

Verification (Node):

function readUtf16Buggy(bytes) {
  let end = 0;
  while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;   // low byte only
  return bytes.toString('utf16le', 0, end);
}
readUtf16Buggy(Buffer.from('D:\\repro\\检测工程参数是否一致', 'utf16le'))
// -> 'D:\\repro\\检测工程参数是否'   (truncated)

Suggested fix / 修复建议

Test the full 16-bit code unit (both bytes) for NUL:

// fixed
while (end + 1 < bytes.length && (bytes[end] !== 0 || bytes[end + 1] !== 0)) end += 2;

With the fix, all tested cases pass, including "一致" in the middle or at the
end of the path. (A patch script for the built worker.cjs is available; happy
to share if useful.)

Impact / 影响范围

• Any Chinese/Japanese/Korean path whose characters have a UTF-16LE low byte of
  0x00 (e.g. 一 U+4E00, and other CJK chars in the 0x00xx range of the low
  byte) cannot be picked via the native Windows folder dialog.
• The same bug also truncates any path containing such characters, and the
  truncation is silent until realpath fails — confusing for users.
• Browse-based picker (dsh-host-directory-picker-browse) is NOT affected
  (uses Node fs dirent names directly).

[nokkies]

Confirmed and reproduced from your example path, and your root-cause analysis is exactly right.

A UTF-16LE terminator is a whole code unit, so both bytes must be zero. Testing only the low byte mistakes any character encoded 00 xx for the end of the string, and U+4E00 一 is 00 4E.

Fix

while (end + 1 < bytes.length && bytes.readUInt16LE(end) !== 0) end += 2

The existing loop guard end + 1 < bytes.length already proves both bytes are in range, so readUInt16LE needs no new bound.

Why the existing tests could never have caught it

This is the part worth recording. The package's suite has driven a CJK path since it was written — C:\选中\directory — so it looks covered. But 选 is U+9009 (09 90) and 中 is U+4E2D (2D 4E), and both have non-zero low bytes. Chinese coverage was present and structurally incapable of reaching the bug.

The regression test needs a character that specifically has a zero low byte. #4654 reports the same defect with a good second example: 软件开发 truncating to 软件, where 开 is U+5F00.

Scope check

I swept the tree for the same class while I was in there: this is the only place a NUL terminator is located by scanning. sandbox-windows-acl decodes by the API-reported length instead (buffer.subarray(0, length * 2)), which is structurally immune.

#4648 is the same root cause seen from the outside — a folder mixing English and Chinese that simply cannot be selected as a workspace — so all three reports collapse to this one line.