fix(scanner): support non-ASCII project paths and plugin-provided skills

[levelfly]

Summary

Two related gaps in scanner.mjs that become visible on Windows when project paths contain non-ASCII characters (CJK etc.) and when skills are shipped by installed plugins.

1. Non-ASCII project path decoding

Claude Code encodes real paths into ~/.claude/projects/ directory names by replacing every non-alphanumeric character with -. A path containing CJK characters produces runs of trailing dashes — one per path separator and one per CJK character.

The existing segment-based resolver splits the encoded name on -, DFS-matches each segment against real directory entries, and can never match the empty segments produced by runs of CJK characters. When it returns null, discoverScopes() silently drops the project via if (!realPath) continue — every non-ASCII-path project disappears from the sidebar, along with its memories and sessions.

Fix: three resolution strategies tried in order:

1. resolveViaSessionCwd() — reads the first few .jsonl files in the encoded dir and pulls the cwd field. Ground truth from Claude Code itself; no pattern guessing, and it handles the unavoidable encoding collision where two sibling CJK dirs of equal length collapse to the same string.
2. Existing segment resolver — unchanged, still fast for ASCII paths.
3. resolveEncodedProjectPathUnicode() — character-level pattern matcher. Crucially, - in the encoded name is not a pure wildcard: since the encoding preserves [A-Za-z0-9-], an encoded - means the original char was not alphanumeric. Treating - as "matches any non-alphanumeric char" correctly rejects a purely numeric name against a pattern of all dashes (digits would have encoded as digits, not dashes), while still accepting CJK names.

If all three fail, the project is still accepted rather than silently dropped. A new prettifyEncodedPath() generates a readable fallback name by turning runs of dashes into …, and scanMemories / scanSessions work fine because they only need scope.claudeProjectDir (the encoded path), not the real repoDir. Downstream code that reads scope.repoDir (e.g. MCP project config lookup) already handles the null case.

A post-pass disambiguates duplicate basenames by prepending the parent directory when two projects share a basename.

2. Plugin-provided skills

README says Skills covers "Personal, Project, and installed Plugins", but scanSkills() only reads the first two. Plugins installed via claude plugin install live at ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/ and commonly ship a skills/ subdirectory. None of those skills render in the dashboard today.

Fix:

• Extract per-skill reading into a reusable readSkillEntry() helper.
• Read ~/.claude/plugins/installed_plugins.json and scan each plugin's <installPath>/skills/.
• User-scope plugins → Global. Project-scope plugins → matched to the right project by re-encoding the plugin's projectPath via a new encodeClaudeProjectName() helper and comparing to scope.id (the encoded dir name). This tolerates encoding collisions and matches Claude Code's own behavior.
• Plugin skills get subType: \"plugin-skill\" and bundle: <pluginName> so the UI can distinguish them.

Test plan

• Fresh reinstall via npx @mcpware/claude-code-organizer, non-ASCII-path projects render in the sidebar with decoded names
• Memories and sessions inside non-ASCII projects are listed
• ASCII-only projects still resolve via the fast segment resolver (unchanged path)
• Duplicate basename disambiguation works
• Encoding collision: when two sibling paths encode to the same string, resolveViaSessionCwd picks the one whose sessions are actually present
• Plugin skills from both user-scope and project-scope plugins appear in the correct scope with the plugin name as bundle label

All changes are isolated to src/scanner.mjs. No schema / API / UI changes.

Note: this is a resubmission of a previous PR that was closed due to stray personal paths in the description. The fix itself is unchanged.