Chat file links to non-ASCII (CJK) paths are silently no-ops (click does nothing)

Environment

• Claude Code VSCode extension: anthropic.claude-code-2.1.233-darwin-arm64
• VSCode (also reproduced on VSCodium), macOS (Darwin 24.6.0, arm64)
• Workspace file names containing CJK characters (common for zh-CN users)

Steps to reproduce

1. Open a workspace that contains a file with a CJK filename, e.g. output/doc/PRD-科研站-三年级用语整改与学习材料库-v0.1.md
2. In the chat panel, Claude renders a file link such as [PRD](output/doc/PRD-科研站-三年级用语整改与学习材料库-v0.1.md)
3. Click the link → nothing happens: no editor opens, no error, no notification
4. Click a link whose path is pure ASCII (e.g. logs/LOG_INDEX.md) → opens normally

Expected

CJK-path links should open the file exactly like ASCII-path links.

Likely root cause (from inspecting extension.js 2.1.233)

• The webview contains many encodeURIComponent call sites; the path received by the host side appears to be URL-encoded for non-ASCII segments.
• The host-side openFile(e) computes isAbsolute(e) ? e : join(cwd, e) then existsSync(r) — this fails when e carries percent-encoded CJK segments. The fuzzy fallback search doesn't match either.
• ke.window.showTextDocument(n).then(...) has no .catch, so the resulting promise rejection is swallowed → the click is a silent no-op.

Notes

• workbench.editorAssociations (*.md → vscode.markdown.preview.editor) does not apply to these links, since the extension opens them via showTextDocument directly — related but separate from #issue about preview mode.
• Workaround for users: open the file from the Explorer, or keep file names ASCII.

Suggested fix

Decode the path (decodeURIComponent) before resolving in openFile, and/or resolve via the original (unencoded) string carried in the message data instead of the rendered href; add a .catch that surfaces a warning when a link target cannot be resolved.