Content Drive: listing payload carries long-text field values the grid never renders

Description

Every row POST /api/v1/drive/search returns for a generic Content item carries the full value of that contentlet's long-text fields (WYSIWYG, TextArea, Story Block) even though the listing is a grid of names, types, and dates. On the benchmarked dataset a 40-row page measured 159 KB, of which 116 KB (~73%) was a single long-text field. The cost is paid on serialization, on the wire, and in browser memory.

The Content Drive grid does render arbitrary content-type fields when a field is flagged "Show In List" — including long-text ones, with no field-type restriction — so an unconditional removal would silently blank that column for any content type configured that way.

Decision: truncate long-text field values to 150 characters rather than removing them, applied uniformly whether or not the field is listed. This bounds payload regardless of configuration and preserves the Show In List column as a preview instead of a blank cell. The frontend already visually clips these cells with CSS (truncate/ellipsis) — that's a display-only clip of the full string already in the response, so server-side truncation is what actually removes the bytes; no frontend change is required.

Acceptance Criteria

• Long-text field values in POST /api/v1/drive/search listing rows are truncated to 150 characters, not transferred in full
• Payload for a 40-row page of long-body generic Content drops by at least half versus current behavior
• A content type with a listed long-text field still renders that grid column, showing the truncated preview, not blank and not the full body
• Every field the Content Drive grid, its toolbar, and its action menu consume is unchanged
• The dead item.body read in the Postman collection's "Text Search - Alpha Filter" test is removed or replaced with an assertion that actually runs
• POST /api/v1/content/_search, GraphQL, the Content Editor, and the asset picker / File field are unaffected
• A content type whose title field is itself a long-text field still returns a correct title

Parent Epic

#36814