docs(api): INVALID_FIELD's searchFields clause covers the two value-shape refusals (#16269)

The searchFields parenthetical in the INVALID_FIELD Cause only described the
"real field outside the searchable set" refusal. It did not cover the two
shape refusals raised by assertSearchFieldsAreSearchable (an array entry that
is not a string, and a value that is neither a comma-separated string nor an
array) — both of which throw the same code/status/param, just on a different
axis of the value. This is a coverage gap in one clause of the Cause text, not
a second meaning for the code (#15882).


Claude-Session: https://claude.ai/code/session_01Vbw3RPgdtqesx4azk9SbW8

Co-authored-by: Claude <noreply@anthropic.com>

Author: baozhoutao

content/docs/api/error-catalog.mdx

@@ -75,7 +75,10 @@ reads those as field filters, so one naming no field could only match zero
 records and is rejected rather than answered with an empty page — plus every
 other read axis that names a field: `select`, `expand` (a real field that holds
 no reference gets its own message), `searchFields` (a real field outside the
-searchable set gets its own message), `groupBy`, and `aggregations[].field`.
+searchable set gets its own message, and so does a value with the wrong shape —
+an array entry that is not a string, or a value that is itself neither a
+comma-separated string nor an array of field names), `groupBy`, and
+`aggregations[].field`.
 Off the request path the same code answers `backfillSummaryNulls`'s
 `recomputeUndefinedOnEmpty` (`os migrate summary-nulls
 --recompute-undefined-on-empty object.field`) when an entry is not a roll-up