[Bug] 从聊天引用点开文件时右侧预览失败：fs-error "… is not an absolute path"（Windows）

[NekoDD-wow]

环境

• DSH: 0.1.5-rc.2（已确认 master 与 0.1.6-alpha.2 同样存在）
• 平台: Windows 11 (10.0.22631)
• 工作区路径含中文，例如 E:\py\output\aiouput\测试

复现步骤

1. 工作区内存在文件，例如 拖拽动图/1.png
2. 从聊天里的文件引用点击打开（不是从右侧 Files 文件树）
3. 右侧预览标签页打开，但内容区显示破图 / 无法加载

实际报错（客户端）

{"ok":false,"error":{"code":"fs-error",
  "message":"\"拖拽动图/1.png\" is not an absolute path"}}

对照现象

同一个文件、同一个路径，从 Files 文件树点开是正常的。
也就是说：入口不同，结果不同。

根因分析

packages/client/ui-chat/src/client/apply.ts：

openFile: async (path, options) => {
  const cwd = ctx.sessions.list.getSnapshot().byId[sessionId]?.cwd
  const url = fileAddressFor(sessionId, cwd, path)
  ...
}

fileAddressFor(sessionId, cwd, path) 在 cwd 已知时会把工作区根目录剥掉，
使地址里只保留工作区相对路径（这是 packages/util/workspace-path/README.md 记录的既定设计）。

服务端 dsh-api-workspace-files 的 locateFile() 随后执行：

const target = await this.ctx.fs.resolve(path, { cwd: workspaceRoot, signal });

但该相对路径没有被 workspaceRoot 成功解析，最终抛出：

fs-error: "<path>" is not an absolute path

而 Files 文件树入口产生的地址里是绝对路径（cwd 为空时 fileAddressFor 保留绝对路径），
所以不受影响。

建议修复（任一）

• 方案 A（最小改动）：apply.ts 中改为 fileAddressFor(sessionId, undefined, path)，
  使地址保留绝对路径。
• 方案 B（更根本）：让 WorkspaceFiles.locateFile() 正确使用
  workspaceFileScope.workspaceRoot 解析工作区相对路径。

临时绕过（已验证有效）

把打包产物 dsh-client-ui-chat/lib/client.js 中，
const cwd = ...?.cwd; const url = fileAddressFor(sessionId, cwd, path);
改为 const url = fileAddressFor(sessionId, void 0, path);，刷新页面后恢复正常。

相关讨论

• 反馈报告：Web GUI 文件链接（产物行 / 行内代码）点击无任何反馈，表现为「死链接」 #1286 Web GUI 文件链接点击无反馈（「死链接」）
• [Feature/客户端契约] openFile 缺少官方“外部编辑器”出口：宿主内嵌（VS Code 面板 / 桌面壳）时点文件只能落回 DSH 右侧栏预览 #6573 openFile 缺少官方「外部编辑器」出口
• 在使用dsh-better-sidebar插件的引用功能时，发现dsh会自动将文件识别为绝对路径，从而导致找不到文件报错。 #4363 Windows 下 /path 被判定为绝对路径（同类路径作用域问题）

[unifilitence]

同入口的文件夹变体（补充）：聊天正文里的文件夹路径链接，点击后在右侧同样打不开——而且比文件的路径解析问题更深一层：是能力缺口，不只是解析失败。

复现：让 agent 在回复正文里引用一个工作区内的文件夹路径（渲染为链接）→ 点击 → 右侧侧边栏无反应/失败，且该文件夹的预览头部没有「在文件夹中显示」或「打开方式」控件（文件路径则有完整控件：默认图标 + 下拉 + reveal）。

代码层证据（0.1.7-rc.2 官方安装版 asar 抽取）：

1. 预览体类型清单（Text/Html/Pdf/Excel/Image/Office/Font）没有 directory 类型——文件夹即使路径解析成功也没有可渲染的 body（抽取件：dsh-client-ui-sidebar-documentpreview/lib/client.js 的预览体注册表）；
2. 「打开方式」下拉与「显示文件位置」控件挂在文件预览头部（kind: "file" 作用域），文件夹路径不渲染这套控件。

建议（分层）：

1. 最小：文件夹路径的链接至少给「在文件夹中显示」（revealNativePath 对目录 = explorer /select,<目录> 选中该文件夹）——该链路在本机已解除隐藏（见 deepseek-harness#7842 讨论中的 windowsHide 修正，reveal 实测可用），机制相同推定可用；
2. 进阶：给目录一个轻量预览体（列出目录内容），与 Files 树互补；
3. 关联：聊天正文的路径进预览前还需过本帖的路径解析层（相对路径 → 绝对路径）——两层都要过才算闭环。

环境：Windows 11 (build 26200)；Desktop 0.1.7-rc.2（官方安装版）。