Resolve people search by pubkey and alias

[vincenzopalazzo]

Summary

• Desktop people search (members sidebar, DM picker, @mentions, topbar people) returned zero results for pubkey hex and often for aliases
• Root cause: pure kind:0 directory queries only hit NIP-50 FTS over kind:0 content. Author pubkeys are not in that index, so hex search can never match; the existing buzz_db::search_users (name / NIP-05 / pubkey) was unused
• Fix: route pure kind:0 search filters on the HTTP bridge through the users table, prefer real stored kind:0 profiles when present (keeps NIP-OA agent tags), synthesize a directory-shaped kind:0 otherwise, and score mid-string pubkey matches in the desktop re-ranker

Test plan

• cargo test -p buzz-relay --lib people_directory / synthetic_kind0
• desktop unit: rank_matches_mid_string_pubkey_hex
• cargo check -p buzz-db -p buzz-relay
• CI green (relay image rebuild required for staging/prod)
• Manual against a relay with this fix: open Members → search a known display name / NIP-05 local part / pubkey prefix → results appear
• Manual: search by mid-string pubkey hex substring → result appears
• Manual: message search / channel-scoped search still uses FTS (unchanged path)

Related: mobile add-people surface is #1706 (separate gap). This PR is the search backend that both clients depend on.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2f10f8424f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[wesbillman]

From my agents...

I found two blocking correctness issues in the new directory path:

1. Deleted kind:0 profiles are resurrected from stale users fields. NIP-09 soft-deletes the event, but handle_standard_deletion_event does not clear the denormalized profile columns. The new stored-event lookup then finds no live event and synthesizes a kind:0 containing the old name/avatar/NIP-05. Deleted profile data therefore reappears in every people-search surface. Please make deletion update the profile cache (with ordering/republication semantics) or explicitly distinguish “never had a profile” from “profile deleted” before synthesizing, and add an integration test covering publish → delete → search.

2. OFFSET paging is unstable for ties. search_users orders by score and a non-unique display label only. Users sharing both (for example many “Alex” rows) can move across page boundaries, causing duplicates and omissions. Add pubkey hex as a final deterministic key and test tied rows across pages.

Also, this branch is now 149 commits behind main and overlaps changed buzz-db APIs, so it must be rebased and fully revalidated. Current GitHub CI has only DCO/Semgrep/zizmor; there is no relay/Rust/Desktop run to gate the change.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[vincenzopalazzo]

@wesbillman Fixed in dbbca47. Rebased onto current main, added deleted-profile history detection plus publish → delete → search coverage, and made tied pagination deterministic by pubkey with a page-boundary regression test. Validation: just ci passed; both new Postgres/live-relay regressions passed explicitly; every real just test group passed. The test wrapper still exits 1 on its pre-existing buzz-auth --test * no-target probe.