fix: stem chat search terms with the english text search config - #28319

Chat full-text search used the 'simple' text search config, which folds
case but does no stemming, so searching "refactor" did not match
messages containing "refactoring". Switch every chat search site
(chat titles, PR titles, and message bodies) to the 'english' config so
inflected word forms match.

The config baked into a tsvector must match the config used by the
tsquery, so a migration rebuilds the two expression indexes and resets
chat_messages.search_tsv to NULL; the existing dbpurge sweep repopulates
the column with 'english' lexemes in bounded batches, newest first.

A side effect of 'english' is stopword removal: queries consisting only
of stopwords (e.g. search:"or") now tokenize to nothing and return an
empty list, matching the existing empty-after-tokenization contract.

Address review feedback on the english text search config switch:

The migration no longer rewrites chat_messages. A full-table UPDATE of
search_tsv would rewrite every indexed row inside the migration
transaction, churn both partial indexes, and hold row locks and WAL
until the batch commits.

Instead a new search_tsv_config column records which config produced
each stored vector. The pending-queue index and backfill sweep treat
any row whose config is not 'english' as pending, so the existing
bounded dbpurge sweep re-vectorizes the backlog incrementally, newest
first. Old binaries in a rolling upgrade cannot set the column, so any
'simple' vectors they write stay pending and are rewritten by an
upgraded replica's sweep instead of being stranded with mismatched
lexemes.

Both chatd trigger functions now exclude search_tsv_config alongside
search_tsv so backfill batches do not advance message revisions or
chat history_version.

…config

During the post-migration drain window, message vectors not yet
rewritten by the sweep still hold 'simple' lexemes, and an old replica
in a rolling upgrade can add more. Querying those rows with an
'english' tsquery misses them even for the exact word form users typed
before the config switch (stored lexeme 'refactoring' never matches
the stemmed query 'refactor').

GetChats now matches each vector with the config that produced it:
rows stamped 'english' use the stemmed query, rows with a NULL
search_tsv_config use the 'simple' query, preserving their
pre-migration matching until the sweep rewrites them. Both arms use
constant tsqueries, verified via EXPLAIN to plan as a BitmapOr of two
scans over idx_chat_messages_search_tsv; once the backlog drains the
'simple' arm matches no rows.

…ent sweep

On rollback, rows the upgraded sweep re-vectorized held 'english'
lexemes while the parent binary queries with 'simple' and its backfill
only selects search_tsv IS NULL rows, so those rows were never
repaired.

The down migration now resets search_tsv to NULL for rows stamped
search_tsv_config = 'english' before dropping the column, handing
exactly the affected set back to the parent's bounded dbpurge sweep.
Rows never re-vectorized keep their valid 'simple' vectors. The reset
runs while the replacement trigger functions are still installed, so
it does not advance message revisions or chat history_version.

…ckend-search-improvements-to-handle-partial-matches

…explicitly