feat(i18n): add unused key cleaner

[kangfenmao]

What this PR does

Before this PR:

Unused i18n keys had to be identified manually or through editor tooling, and there was no repo-level command to safely clean obsolete translation keys across locale files.

After this PR:

Adds pnpm i18n:unused to scan unused i18n keys, report grouped results, optionally output JSON, and clean selected namespaces across locales and translate files. It also supports pnpm i18n:unused --clean --all for explicit non-interactive cleanup of all unused keys. The scanner uses conservative matching rules to avoid deleting keys referenced through dynamic or indirect code paths, including main-process i18n.translation namespace aliases.

Fixes #

Why we need it and why it was done in this way

The following tradeoffs were made:

The cleaner is intentionally conservative. Exact key strings and known dynamic patterns are treated as used, which may preserve some truly unused keys but reduces the risk of deleting keys that are still referenced indirectly.

The following alternatives were considered:

Relying only on AST patterns was considered, but it missed valid usages such as key maps, conditional t() arguments, and main-process namespace aliases. A full runtime-aware analysis would be more complex and less practical for this maintenance command.

Links to places where the discussion took place: N/A

Breaking changes

None.

Special notes for your reviewer

This PR also removes the unused keys currently detected by the new scanner after rebasing on v2. The scan result is 0 unused keys after cleanup.

Validated main-process usage such as trayLocale.show_quick_assistant is preserved by alias-aware scanning.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

NONE

[DeJeune]

LGTM