People search should match chosen and full/verified names

🤖 Filed by Fizz, an AI agent, from a Buzz feature-request thread.

## Problem

Buzz lets people choose expressive profile/display names, which is valuable, but
it makes coworkers difficult to find when someone only knows their real or
workplace name.

For example, searching for `Jane Smith` should find a coworker whose chosen
display name is `night bee`, without requiring the searcher to already know that
alias or the person's pubkey.

This affects every people-finding surface:

- global people search;
- `@` mention autocomplete;
- DM recipient selection;
- channel member/add-people pickers.

## Requested behavior

Keep user-chosen profile names expressive while making a separate human/full
name searchable:

- Let a person have both a chosen profile/display name and a human/full name.
- Match people queries against both values, case-insensitively and by substring.
- When the values differ, show both in results so the person can be
disambiguated, for example `night bee · Jane Smith`.
- Use the same matching and result-label behavior across Desktop and Mobile.
- Continue treating the pubkey as canonical identity; neither name needs to be
globally unique.

Prefer a single **Full name** field over requiring Western-style first/last
fields. In corporate communities, the existing relay-verified identity name can
serve as the authoritative full name. In communities without that identity
source, an optional self-supplied full name is a product choice.

## Privacy and trust

- Do not make a new full-name value public outside its existing visibility
boundary merely to support search.
- A relay-verified corporate name should remain distinguishable from
self-supplied profile metadata.
- Search results should preserve the existing verified-name affordance when one
is available.

## Acceptance criteria

- [ ] A person with chosen name `night bee` and full/verified name
`Jane Smith` is returned for searches matching `night`, `Jane`, or
`Smith`.
- [ ] Global people search, mention autocomplete, DM recipient selection, and
channel member pickers use the same multi-name matching behavior.
- [ ] Results show both names when they differ and retain the verified-name
affordance where applicable.
- [ ] Exact duplicate labels remain distinguishable using existing identity
metadata without changing pubkey identity.
- [ ] Desktop and Mobile have equivalent behavior.
- [ ] Tests cover chosen-name matches, full/verified-name matches, substring and
case-insensitive matches, identical-name deduplication, and visibility
boundaries.

## Related work

- #2796 / #3342 separate Nostr `name` from `display_name` in Desktop profile
flows.
- #1476 adds relay-verified corporate identity names and displays the verified
name alongside the chosen name.
- #2529 adds substring matching to user-picker searches.
- #402 added Mobile people search.

Those pieces establish the profile and search foundations, but none currently
defines consistent people-search matching across both the chosen name and the
human/verified name.

## Source

Reported in Buzz channel `buzz-feature-requests`, thread event
`1fb30784c0d990cab6fb4c0864a68d1d6590eddb132a662c1ce653e84135c610`.

Start by reviewing the existing people-finding surfaces and the related issues #2796, #3342, #1476, #2529, and #402 to map current profile, verified-name, and substring-search behavior. Done means consistent chosen/full-name matching and labels across global search, mentions, DM selection, channel pickers, Desktop, and Mobile, with the listed privacy and identity tests passing.

Written by the indexing model from the issue text.