Profile search index does not index individual words in names

## Problem Profile search only indexes the **full** `name` and `display_name` strings. Individual words within multi-word names are not indexed, making it impossible to find profiles by searching for non-first words. **Example:** A profile with `display_name = "The Fishcake"` is indexed only as `"the fishcake"`. Searching `"fishcake"` does not find it because: 1. `MDB_SET_RANGE("fishcake")` positions the cursor at the first key >= `"fishcake"` in sorted order 2. Since `'f' < 't'`, the cursor starts far before `"the fishcake"` in the index 3. The 128 result limit is exhausted iterating through unrelated profiles (`"five"`, `"fl justin"`, `"grinder"`, ...) before reaching `"the fishcake"` Similarly, searching `"grinder"` won't find `"The Grinder"`. **User report:** https://github.com/damus-io/damus/issues/3504 (if it exists) or see screenshots below. ## Screenshots Searching `"the fish"` correctly finds "The Fishcake" (because the full indexed name `"the fishcake"` starts with `"the fish"`):  But searching `"fishcak"` does **not** find "The Fishcake" — only profiles whose full name starts with "fishcak" appear (like "Fishcake Bot"):  ## Root Cause In `ndb_write_profile_search_indices()` (nostrdb.c), only two index entries are written per profile: 1. The full `name` (e.g., `"thefishcake"`) 2. The full `display_name` (e.g., `"the fishcake"`) No entries are created for individual words within the name. ## Proposed Fix Modify `ndb_write_profile_search_indices()` to also index each word within `name` and `display_name`. For `"The Fishcake (android)"`, create index entries for: 1. `"the fishcake (android)"` — full name (existing behavior) 2. `"fishcake (android)"` — starting from 2nd word 3. `"(android)"` — starting from 3rd word This way `MDB_SET_RANGE("fishcak")` immediately finds the `"fishcake (android)"` entry. A new migration entry in `MIGRATIONS[]` would be needed to rebuild the search index for existing profiles. ## Related - #115 — `ndb_search_profile_next()` does not validate query prefix (complementary issue about iteration, not indexing) - #49 — Delete old profile search indices when profile is updated