⌘K global-search palette recall is strictly narrower than the `$search` executor (no pinyin/companion recall)

[huangyiirene]

Symptom

The ⌘K command palette's recall is strictly narrower than the $search executor's. hnkj / huaningkeji return 0 hits from the global endpoint while POST /api/v1/data/showcase_account/query {search:…} returns the CJK row; the seeded CJK account is unreachable by huaning from the palette. Net user effect: pinyin recall works in the list quick-search but not in the ⌘K command palette.

The rest of the item passes: exactly one GET /api/v1/search (no per-object fanout), grouped hits (#3371 does not reproduce), Enter navigates, empty / 1-char input fire zero requests, and the RLS deny side is clean on both API and UI.

Root cause

packages/metadata-protocol/src/protocol.ts searchAll builds its own filter (TEXT_TYPES + f.searchable===true, falling back to the title field) instead of calling resolveSearchFields / expandSearchToFilter, and never ORs the SEARCH_COMPANION_FIELD — so full-pinyin / initials recall via the __search companion is absent from this path. Its comment claiming "case-insensitive substring matching via $contains" is also stale — the same $contains case bug tracked in #7641 (shared $contains/case-fold root cause).

Confirmed still present on origin/main (76d74ecb): searchAll (lines ~7177–7291) still constructs its own TEXT_TYPES + searchable===true filter with the stale $contains comment at line 7291, and references neither SEARCH_COMPANION_FIELD nor resolveSearchFields / expandSearchToFilter.

Reproduction

GET /api/v1/search?q=hnkj → 0 hits
GET /api/v1/search?q=huaningkeji → 0 hits
POST /api/v1/data/showcase_account/query {"search":"hnkj"} → returns the CJK row

Source

Extracted from the QA run #7629 (framework 92f26f7, console 6314e87f).