Discovery surface: report searchable columns, and make multi-database tool sets distinguishable #40

Additional item, from review on #43: the schema overview has no row cap while the column list does.

DEFAULT_MAX_COLUMNS exists so one wide table cannot flood the context, but the no-argument path — the one an agent calls first, unprompted — returns a row per table with no bound. A database with a few thousand tables floods exactly the context the other branch protects.

Fix is a LIMIT on table_overview_sql() plus a truncated_at in the payload, mirroring what the per-table branch already does. Left out of #43 to keep that PR scoped; it belongs with this issue since both are about what the agent can learn about a workspace.

A concrete case for part 1, found 2026-08-13.

sql_tool_description's bm25_search paragraph is unconditional — only the example varies on
search_table/search_column. So an agent whose database has no BM25 index anywhere is still
told to "prefer this whenever the answer aggregates over the matches", for a function that would
hard-error, BM25 having no brute-force fallback.

Measured once: an agent with SQL and schema tools only, over a span table with no index, asked
"Which span names contain 'chart-data'? Use text ranking if you can." — it wrote
name ILIKE '%chart-data%' and did not reach for the TVF. One sample, against a prompt that
never mentions BM25, so the risk is unconfirmed rather than disproved.

Deliberately not "fixed" by conditioning the paragraph on a registered corpus, because that
would remove the composable route from every caller who has an index but did not pass
search_table — trading a hypothetical error for a certain loss of capability, on one sample.

Part 1 of this issue is the actual fix: once the agent can ask what is searchable, the
description can point at discovery rather than assert availability. Noting it here so the
motivation is recorded rather than rediscovered.

Measured: a provider-backed index adds a column that describe reports as ordinary data

Found while shipping #39's semantic search. This makes part 1 of this issue worth more than
tidy-up, and the machinery for it now exists.

Building a provider-backed vector index — one created with embedding_provider_id, over a
text column — materialises a generated vector column beside the source. Indexing content
produced content_embedding (List(Float32), 1536 wide), and it appears in
information_schema like any other column, so hotdata_describe_tables reports it with a
non_null count and nothing to distinguish it from data someone loaded.

Verified in front of an agent (gpt-5.1, one-sentence system prompt, 500-row corpus). Asked what
columns the dataset has and which are worth analysing, it did not misunderstand the column
— it inferred correctly from the name and type that this was the vector representation used for
semantic search. It then recommended work that cannot be done here:

content_embedding (List(Float32), 500 non-null) — Vector representation of content
used for semantic search. […] Essential for similarity search and clustering. You'd analyze
it indirectly: clustering listings (e.g. "peaceful/green" vs "downtown/urban") or visualizing
in 2D via dimensionality reduction.

and carried it into the closing "you'll get the most value from" set. Neither clustering nor
dimensionality reduction is reachable through these tools or the engine, so this is an
unbuildable suggestion offered with the same confidence as the real columns — not a wrong
answer, but a real cost, and a user takes it at face value.

The secondary risk is untested but obvious: nothing stops a model writing
SELECT content_embedding FROM …, which returns 1536 floats per row.

What this changes about part 1

The filter needs no new API call beyond the one this issue already proposes.
hotdata_langchain/indexes.py (added in #39) already has it:

• generated_vector_columns(indexes) yields exactly these columns, and
• SearchIndex.vector_column carries the name for each provider-backed index

So "report which columns are searchable" and "hide the columns the index generated" are the
same list_indexes call, and part 1 should cover both. The note in this issue about keeping
the no-argument overview index-free still holds — this belongs on the per-table drill-down,
which is also where the column actually shows up.

One wrinkle worth deciding when we pick this up: whether a generated column is hidden or
labelled. Hiding it makes the table read as it was loaded, which is what a user means by
"what columns does this have". Labelling it ("generated by the index that makes content
searchable by meaning") is more honest about what is in storage. I lean hidden for the model-
facing output, since the agent has no use for a column it cannot compute over.