Assistant: `query_catalog` guidance promises a case-insensitive `otherNames` lookup that `list_contains` doesn't do

Part of #1733. Found in the review of #1732.

## Problem

The `query_catalog` docstring in `backend/api/app/services/tools/catalog_tools.py` (around line 140) tells the model:

> `otherNames` is a list field holding every non-scientific name for a taxon, including prior scientific names, so `contains`/`contains_any` on it finds an organism under a superseded name.

But `_compile_predicate` in `backend/api/app/services/tools/catalog_query.py:481` emits `list_contains(col, ?)`, which is an exact, case-sensitive element match. The guidance promises a lookup the compiled SQL does not perform for anything but an exactly-cased name.

## Failure scenario

A user asks "what assemblies do you have for candida auris?". The model emits a filter `{field: "otherNames", op: "contains", value: "candida auris"}`. The stored element is `"Candida auris"`, so `list_contains` is false, the query returns 0 rows, and the assistant reports the organism is not in the catalog — the exact case #1730 was opened to fix.

This is reachable from ordinary user phrasing: users type organism names lowercase, and nothing in the tool schema tells the model to re-case the value.

## Suggested fix

Either:

- normalize case for `contains`/`contains_any` on list fields — e.g. compile to `list_contains(list_transform(col, x -> lower(x)), lower(?))`, so the op matches how the model is told it behaves; or
- state in the docstring that the value must match the stored name exactly, including capitalization, and have the model title-case organism names.

The first is preferable: it makes the tool behave the way its own guidance describes, rather than pushing a casing rule onto the model.

Worth an eval probe on the lowercase phrasing either way.