fix(search): surface exact short profile names

[wesbillman]

Summary

• prioritize exact whole-lexeme matches within short kind-0 prefix searches
• preserve the existing prefix result set, pagination, community/channel scope, hydration, and authorization path
• add a Postgres regression where newer noisy jm… profiles saturate the bounded page

Why

Desktop mention autocomplete starts searching after one character. The jm profile is indexed and matches both jm:* prefix search and standard full-text search, but production prefix search returns a full 50-result page without it. Raw profile JSON supplies enough unrelated jm… lexemes that newer equal-rank matches fill the bounded page before the exact short display name.

Changing clients would leave deployed Desktop 0.5.8 installations broken. This shared search-layer compatibility fix changes ordering only for Prefix + kinds:[0] + query length <= 2; message search, longer profile typeahead, and agent eligibility are untouched.

Validation

At commit ff88761135d5045139aeb3da14d08cbfba203169 with a clean worktree:

• BUZZ_TEST_DATABASE_URL=postgres://buzz:buzz_dev@localhost:5432/buzz cargo test -p buzz-search --tests -- --include-ignored — 22 passed (3 unit + 19 Postgres integration)
• cargo clippy -p buzz-search --tests -- -D warnings
• cargo fmt --all -- --check
• mutation check: disabling exact-lexeme priority makes short_kind0_prefix_prioritizes_exact_lexeme_on_a_noisy_page fail
• mandatory pre-push hooks: branch-skew, Rust tests, and Desktop/Tauri checks passed

Risk

Low. The extra ordering predicate applies only to one- or two-character prefix searches restricted exactly to kind 0. It does not add candidates, bypass filters, or alter access control. Exact matches move ahead of broader prefix matches; all remaining ordering stays relevance, recency, then event ID.

[wesbillman]

Carl re-review on Wes’s behalf at exact head ff88761135d5045139aeb3da14d08cbfba203169: cleared / would approve. (GitHub will not accept an approval from the PR author’s account; the existing independent approval is pinned to this head.)

I traced the SQL construction and caller boundary. The new predicate is limited to Prefix queries whose kinds are exactly [0] and whose normalized input is at most two Unicode scalar values. It changes only ordering: community, deletion, channel, kind, author, time, pagination, canonical refetch, and authorization behavior remain on the existing path. The exact-lexeme check uses the same simple configuration as search_tsv, and deterministic rank/recency/id ordering remains behind it.

Tests changed because behavior intentionally changes: short_kind0_prefix_prioritizes_exact_lexeme_on_a_noisy_page adds a Postgres regression proving the old bounded-page failure and exact-first ordering.

Validation on this exact head:

• cargo test -p buzz-search — 3 unit tests passed; 19 Postgres tests correctly ignored without DB
• cargo clippy -p buzz-search --tests -- -D warnings — passed
• git diff --check — clean
• GitHub CI, including the Postgres-backed/unit and integration lanes, is green

No blocking findings.