Issue -->

The fuzzy search builds a list of words to suggest for typos. It runs word_similarity() over every search field with a 0.3 threshold. On `product.template` that includes `description_ecommerce`, which stores full HTML and can hold tens of kB per record, base64 images included.

With a long text, the 0.3 threshold matches nearly every row. No trigram index can narrow that down, so all the time goes into recomputing word_similarity on the heap. The GIN index from `index="trigram"` makes it worse: it underestimates the number of matching rows, so the planner takes a single threaded bitmap heap scan instead of a parallel seq scan.

Solution -->

Add an optional `fuzzy_search_fields` key to the search details. It falls back to `search_fields`, and `website_sale` uses it to skip description_ecommerce when enumerating words. The field stays in search_fields, so `(=)ilike` still works and still uses its GIN index.

Addionally, remove `_description_ecommerce_gist_idx`. A pg_trgm gist leaf entry holds every distinct trigram of the value, 3 bytes each. Past ~2700 distinct trigrams it goes over the 8191 byte limit for an index row and `CREATE INDEX` fails.

Benchmark -->

One word search on a reference database, 43828 products with an eCommerce description (4.5 kB on average, 68 kB at most). Median of repeated requests, responses identical before and after.

| Route                                       | Before  | After  |
|--------------------------------------------|-------|------|
| GET /shop?search=                           | 11.58 s | 0.87 s |
| POST /website/snippet/autocomplete          | 10.95 s | 0.22 s |

opw-6571788