[BUG] Slash command autocomplete never matches custom commands with non-ASCII (Korean) names — regression

Summary

Custom slash commands whose file name contains Korean (non-ASCII) characters are registered correctly but are never shown in the / autocomplete popup, and typing the Korean characters does not filter to them. ASCII-named custom commands in the same directory work normally. This used to work in an earlier version.

Environment

• Claude Code 2.1.220 (native binary, auto-update channel latest)
• Windows 11 Pro 26200, PowerShell, TERM=xterm-256color, tui: fullscreen
• Commands in <project>/.claude/commands/

Steps to reproduce

1. Create .claude/commands/테스트.md with normal frontmatter (description, argument-hint).
2. Create .claude/commands/test-ascii.md with the same structure.
3. Restart Claude Code, type / in the input box.

Expected

Both /테스트 and /test-ascii appear in the popup; typing 테 filters to /테스트.

Actual

• /test-ascii appears and filters normally.
• /테스트 never appears in the popup, at any scroll position.
• Typing 테 after / yields no match.
• The command is registered — it appears in the model's available-commands context, and typing the full name /테스트 + Enter executes it.

Notable: the agents view is not affected

Searching Korean text in the agents view works correctly in the same session and same terminal, so this is not an IME or terminal input problem — it is specific to the slash-command popup's matching path.

Regression

This worked in an earlier 2.1.x release. I cannot name the last-known-good version — the machine has auto-updated through 2.1.208–2.1.220 and the breakage was only noticed now.

Guess at the cause

The popup appears to normalize command names to ASCII before matching (a Korean name would normalize to an empty string and match nothing). Not verified — the binary is compiled, so I could not confirm which code path is responsible.