Non-ASCII (Cyrillic) username in path corrupts project-slug, breaking session/memory continuity

Description

On Windows, when the home directory path contains non-ASCII characters (tested with a Cyrillic Windows username, e.g. C:\Users\админ\...), claude.exe corrupts those characters when computing the internal "project slug" used to name the ~/.claude/projects/<slug>/ storage folder (session transcripts + project-scoped auto-memory).

Each non-ASCII character in the path appears to be replaced by a dash. For example:

• Real path: C:\Users\админ\projects\agent
• Correct expected slug: C--Users-админ-projects-agent
• Actual slug produced: C--Users-------projects-agent (7 dashes where админ, a 5-character username, should be — 5 corrupted chars + 2 normal path-separator dashes)

New sessions started from that directory land in the garbage/corrupted slug folder — which is effectively empty/disconnected from any prior session history or memory previously stored under the correct slug — instead of reusing the existing project folder. This breaks session resume and Claude Code's project-scoped auto-memory for any user whose Windows profile path contains non-ASCII characters.

Steps to reproduce

1. On a Windows machine with a non-ASCII (e.g. Cyrillic) account username, so %USERPROFILE% contains non-ASCII characters.
2. cd into any directory under that profile, e.g. %USERPROFILE%\projects\myrepo.
3. Run claude -p "ping" (or start an interactive session).
4. Inspect %USERPROFILE%\.claude\projects\ — a new folder is created whose name has the non-ASCII path segment replaced by dashes, instead of matching the correctly-encoded slug for that path.

Additional findings

• Reproduces on both the latest channel (2.1.207) and the stable channel (2.1.197) — not a recent regression from a single release.
• Reproduces regardless of the invoking shell (tested from both PowerShell 5.1 and Git Bash/MinGW) — not a console-codepage artifact.
• An ASCII-only path (e.g. C:\ztest_ascii_dir) produces a correctly-formed slug (C--ztest-ascii-dir) — confirms the corruption is specific to non-ASCII path characters, not a general slug-hashing bug.
• A Windows directory junction pointing an ASCII path (e.g. C:\agent) at the real non-ASCII directory does not work around the bug: claude.exe appears to resolve the junction to its real target path before computing the slug, so the corruption still occurs.

Environment

• claude.exe 2.1.207 (native install) and 2.1.197 (stable channel), both reproduce.
• Windows 10 Pro 10.0.19045, win32-x64.
• Windows account name contains Cyrillic characters (5-character username).

Impact

Any user with a non-ASCII OS username/profile path loses Claude Code's session-resume and project-scoped auto-memory continuity for all local sessions — new sessions silently start "fresh" every time instead of picking up prior context, with no error or warning surfaced to the user.