fix(ui): resolve dotted listSearchableFields paths in the search placeholder

[Minhal128]

What?

With admin.listSearchableFields set to a dotted path, the list view's search box says "Search by ID" while the search actually matches the field you configured.

fields: [{ name: 'items', type: 'array', fields: [{ name: 'value', type: 'text' }] }],
admin: { listSearchableFields: ['items.value'] },

Typing filters the rows correctly; the placeholder still claims it searches the row id. The real-world case is form-submissions from @payloadcms/plugin-form-builder with listSearchableFields: ['submissionData.value'].

Why?

The search works because mergeListSearchAndWhere maps each configured string straight to { [path]: { like: search } }, and a dotted path is a valid query path.

The placeholder is built from getTextFieldsToBeSearched, which matched the configured strings against the bare field.name:

if (fieldAffectsData(field) && searchableFieldNames.has(field.name)) {

Two things fall out of that:

• flattenTopLevelFields(fields, { moveSubFieldsToTop: true }) records the dotted path it builds on accessor, but the match ignored it — so 'meta.description' did not resolve either, even though that field is in the flattened list.
• It never descends into arrays, so items.value was not in the list at all.

Nothing matched, listSearchableFields came back empty, and ListControls fell through to searchLabel, which defaults to 'ID'.

How?

Walk arrays alongside what flattenTopLevelFields already hoists, and match on the path.

The bare name is still matched for everything that was reachable before, so a config naming a hoisted group or tab subfield directly (['description']) keeps working. Array subfields are matched by path only — their bare name is not a valid query path, so matching it would just put the placeholder back to naming a field the search does not actually use.

Added getTextFieldsToBeSearched.spec.ts: the array path, the group path, a plain top-level name, a group subfield by bare name, several paths at once, an array subfield not matching by bare name, no match, and the undefined config.

Targeting 3.x

On main the placeholder is a plain "Search" and packages/ui/src/elements/ListControls/getTextFieldsToBeSearched.ts no longer exists, so this is a v3-only bug and a bug fix only — which is what the template says 3.x takes.

Fixes #18201

---

Written with Claude Code, which this repo ships configuration for. What I verified and what I did not: I read getTextFieldsToBeSearched, flattenTopLevelFields, and the placeholder block in ListControls/index.tsx on 3.x, and checked the matching logic against the spec's fixtures by hand. I have not run the test suite or the admin UI locally, so a run of packages/ui would be worth having before merge.