fix(uninstall): preserve independent CLI tool dotdirs (#993)

[Jiaweeee]

Closes #993.

Problem

find_app_files() in lib/core/app_protection.sh adds XDG-style candidate paths derived from a GUI app's display name:

"$HOME/.config/$app_name"
"$HOME/.local/share/$app_name"
"$HOME/.$app_name"

When the display name collides with an independently-shipped CLI tool, mo uninstall <GUI app> silently wipes the CLI's entire state directory. Reproduced on the same machine within minutes:

• Uninstalling Claude.app → ~/.claude (Claude Code CLI: projects, skills, plugins, accumulated cross-project memory) gone.
• Uninstalling OpenCode.app → ~/.local/share/opencode, ~/.config/opencode, ~/.opencode (sst/opencode CLI sessions/snapshots/logs) + the opencode binary gone.

Case-insensitive APFS amplifies the Claude case: $HOME/.Claude built from app_name="Claude" aliases to $HOME/.claude and passes the [[ -e ]] existence check. MOLE_UNINSTALL_MODE=1 then bypasses should_protect_data (intentionally), and the path is unlinked.

Fix approach

The XDG patterns themselves are intentional — tests/uninstall_naming_variants.bats already enforces them for Maestro Studio / Zed / Firefox via issue #377, so removing them would regress. What's missing is a way to distinguish:

• GUI app that writes to ~/.config/<name> or ~/.local/share/<name> itself (Zed, Firefox, Maestro) → cleanup is correct.
• GUI app that happens to share a name with an unrelated CLI tool (Claude Desktop / Claude Code, OpenCode.app / opencode CLI) → cleanup destroys unrelated data.

This PR adds a tight deny-list INDEPENDENT_CLI_DOTDIR_NAMES in lib/core/app_protection_data.sh and a helper _path_belongs_to_independent_cli consulted inside the existing find_app_files per-pattern loop. Match is lowercase + leading-dot-stripped (handles case-insensitive APFS) and scoped to $HOME, $HOME/.config, $HOME/.local/share, $HOME/.cache so unrelated paths never get skipped.

Initial list: claude, opencode, codex, gemini. Easy to extend as more GUI/CLI namesakes show up.

Tests

tests/uninstall_naming_variants.bats — 4 new cases:

1. Uninstalling Claude.app preserves ~/.claude and still removes ~/Library/Application Support/Claude.
2. Uninstalling OpenCode.app preserves all three opencode XDG roots (~/.local/share/opencode, ~/.config/opencode, ~/.opencode) and still removes the Library path.
3. Same for Codex.app / ~/.codex.
4. Regression: uninstalling Zed Nightly still picks up ~/.config/zed / ~/.local/share/zed (deny-list must not over-protect issue [BUG] maestro studio delete #377 behavior).

Full local verification:

• bats tests/uninstall_naming_variants.bats → 16/16 pass (12 existing + 4 new).
• bats tests/uninstall_safety.bats tests/uninstall_remove_file_list.bats tests/uninstall.bats tests/uninstall_scan_bash32.bats → 79/79 pass.
• bash scripts/check.sh → shellcheck + bash syntax check pass; shfmt applied no further changes.

I also patched a local install of Mole 1.39.1 with the equivalent change and confirmed mo uninstall against OpenCode.app no longer lists ~/.local/share/opencode / ~/.config/opencode / ~/.opencode in the deletion preview while still listing the GUI app's ~/Library/Application Support/opencode.

Related context

• [BUG] Mole clean mode permanently destroyed Claude Code user data in ~/.claude/projects/*/memory/ — months of irreplaceable context lost #823 (closed by 32bfb5b9) fixed mo clean wiping ~/.claude/projects/*/memory/ by removing automatic cleanup of ~/.claude/* from lib/clean/dev.sh. Different code path — doesn't cover uninstall.
• mo clean 误删 Claude Code CLI 的 active 版本，导致 claude 命令失效 #801 (closed by 6f13e08) added symlink-aware preservation for ~/.local/share/claude/versions/. Different mechanism.

Neither prior fix touched find_app_files(), which is why the uninstall path regressed independently.

Notes for review

• Deny-list approach intentionally tight rather than heuristic. A "binary on PATH" check would be more generic but would break Zed-style GUI apps that ship a same-named launcher CLI.
• Trash-by-default (so future false positives are recoverable) is out of scope here and probably its own PR.
• Happy to add more entries to INDEPENDENT_CLI_DOTDIR_NAMES if you have other namesakes in mind.