fix(desktop): rank topbar channel results by relevance, not alphabetically

[tlongwell-block]

Problem

The ⌘K topbar channel section had two compounding limiters (surfaced while investigating the buzz-security discovery incident — the incident itself was the deployed relay image missing #2181; this is the separate, real client defect found along the way):

1. Alphabetical ranking under a hard cap of 5. Naive substring matches were sorted alphabetically, then slice(0, 5). Replayed against the live channel list: query buzz has 61 matches and buzz-security ranks 49th alphabetically — it could never appear.
2. No separator tolerance. buzz security (space for hyphen) or buzzsec matched nothing at all.

The Channel Browser (⌘⇧O) already solves both with its banded fuzzy scorer (channelSearchScore.ts); the topbar just wasn't using it.

Fix

New pure helper features/search/lib/channelResultRanking.ts reusing scoreChannelMatch:

• Relevance-ordered (score band ascending, alphabetical tiebreak), cap of 5 unchanged — a relevance-ranked cap is correct typeahead UX.
• Visibility rules preserved exactly: archived only for members; otherwise open-or-member.
• Channel labels (DM display names) scored as the display name, with the raw channel name kept searchable when a label overrides it.
• Description matches stay in the lowest band, below any name match (same contract as the browser).

useSearchResults.ts channel memo now delegates to the helper.

Testing

• 8 new unit tests in channelResultRanking.test.mjs covering the two original failure modes (buzz burying an exact match, buzz security/buzzsec finding buzz-security), visibility filtering, label override + raw-name fallback, description band, and the cap.
• Full desktop suite: 3379 pass / 0 fail at this head; pnpm typecheck and pnpm check clean.