BDMS 774 Fix WELL List filters

[jeremyzilar]

What is changing

Fixes wells list filtering so column filters actually narrow results server side, supports “does not contain” and other Refine operators, forwards multiple filter query parameters from the UI, and makes the wells toolbar search match Thing.name by substring instead of relying on full text search alone.

Problem

• The API applied at most one filter JSON value and only implemented contains, so “Type does not contain water” had no effect and extra filters were dropped when Refine sent several filter= entries.
• The wells search box sent query (full text / search_vector), which often did not behave like searching for a specific well ID or name (for example DE-0229).

API changes (OcotilloAPI)

services/query_helper.py

• order_sort_filter consumes every submitted filter blob (legacy single filter_ plus optional list).
• _apply_json_filter_clause implements Refine logical operators used by the Data Grid, including ncontains, contains, startswith, endswith, eq, ne, comparisons, null / nnull, and in, instead of only contains.

services/thing_helper.py

• get_db_things merges optional filters: list[str] with the legacy single filter and passes them into order_sort_filter.
• Adds optional name_contains to restrict rows with Thing.name ILIKE %value%.

api/thing.py

• GET /thing/water-well, GET /thing/spring, and GET /thing bind filter as a list[str] (repeated query params) and expose name_contains as an optional query parameter.

UI changes (OcotilloUI)

src/pages/ocotillo/thing/list.tsx

• Wells list toolbar passes name_contains (debounced) instead of query so search aligns with substring match on well name.

Deploy / rollout

• Ship API before or together with this UI change: column filters require the API updates; name_contains requires the new API parameter.
• Other list surfaces that share order_sort_filter (sensors, locations, lexicon, samples, observations, contacts, thing id-links, etc.) now honor operators that were previously no-ops.