Fix exact and localized application name ranking

[ChoSeongmin1128]

MiniSearch indexes both name and localizedName, but the relevance tier only checks name. It also assigns exact and prefix matches to the same tier.

This causes two ranking problems:

• An application named Calendar with a localized name such as Kalender is found for kal, but is ranked as a fuzzy match because only Calendar is checked.
• An exact Home query can rank Homebrew first when Homebrew has selection history, because both results are treated as prefix matches.

This change ranks both name and localizedName and separates exact, prefix, word-prefix, substring, and fuzzy matches. Match tiers are calculated once per result before sorting to avoid repeating normalization in the comparator.

In the built app:

• Home ranks above Homebrew for an exact home query.
• Antigravity ranks above Antigravity IDE for an exact antigravity query.
• Direct localized-name matches rank above weaker fuzzy or previously selected results.
• NFC and NFD input produce the same result order.
• Regular and non-breaking spaces produce the same direct match.

Additional checks covered:

• 17 targeted cases across all match tiers, missing localizedName, separator differences, and aliases remaining outside tier calculation
• 20,000 generated name/query pairs for exact and prefix tier behavior
• 869 full-name, prefix, and word-prefix queries derived from 129 installed applications, with no exact match displaced by a weaker result
• sorting 1,000, 5,000, and 10,000 results to verify that match-tier caching avoids repeated normalization overhead
• unchanged MiniSearch result IDs before and after ranking

Aliases, MiniSearch fields and options, and the result set are unchanged.

The production Metro bundle succeeds. bun run typecheck reports the same five pre-existing errors as main.