[BUG] Session list empty in VS Code extension (mapped network drive + non-ASCII path) - related to #31219 and #40946

Description

The "Local" sessions list in the Claude Code VS Code extension shows "No sessions yet" even though session data exists correctly on disk. This appears to be the combination of two previously-reported (and closed as "not planned") issues:

• #31219 — extension resolves mapped network drives via fs.realpath() to a UNC path, causing a mismatch with the directory the CLI actually writes to
• #40946 — non-ASCII path segments are collapsed to -, causing lossy/ambiguous directory naming

Environment

• OS: Windows 11 Pro
• Workspace path: a mapped network drive (Z: → \\<server>\<share>), with non-ASCII (Korean) characters and spaces in the path, e.g. Z:\<Korean>\<Korean> <folder>\<folder>
• Claude Code VS Code extension (Remote Control feature active)

Steps to Reproduce

1. Map a network share to a drive letter on Windows (net use Z: \\<server>\<share>)
2. Open a workspace on that drive whose path contains non-ASCII characters
3. Use the Claude Code CLI/extension to create one or more sessions
4. Close and reopen VS Code
5. Open the Claude Code extension sidebar → "Local" tab

Expected

Previously created sessions for the workspace appear in the list.

Actual

The list shows "No sessions yet", even though ~/.claude/projects/<sanitized-path>/*.jsonl contains valid, recently-modified session files for this exact workspace. Verified the session files exist and are intact — this is a discovery/listing bug, not data loss.

Workaround

None found that uses the extension UI. Using the CLI directly in a terminal (claude --resume or /resume inside a session) does correctly find and list past sessions for the same workspace, since the CLI does not go through the same realpath/UNC resolution as the extension.

Impact

On every VS Code restart, the session history for workspaces on mapped network drives with non-ASCII paths becomes invisible in the UI, even though it's not lost. This is disruptive for workflows relying on the extension's session picker rather than the terminal.

Related: #31219, #40946