feat: schema-aware greetings via a QueryChatGreeter API

[gadenbuie]

Supersedes the constructor-based approach in #260 (kept open for discussion). Credit to @cpsievert for the regression insight and test infrastructure.

Summary

After multi-table support (#195), the schema moved out of the system prompt into a lazy tool_get_schema tool. Greetings are generated by a tool-free client, so the model became schema-blind when writing the opening message — it could no longer describe the data it was about to chat about.

This PR fixes that with a dedicated greeting API rather than a constructor parameter. The greeting-specific concern lives on a new semi-internal QueryChatGreeter, reached via qc$greeter (R) / qc.greeter (Python), instead of widening the QueryChat constructor for every single-table user.

Key design decisions:

• QueryChatGreeter holds $tables (table names whose schema to embed in the greeting) and $prompt (the greeting template). It is semi-internal — accessed through qc.greeter, not separately constructed (R class is @noRd). Setters store only; changing greeter config never invalidates an existing qc$greeting, so a user-supplied static greeting always survives.
• Separate greeting system prompt (greeting.md) instead of the full prompt.md. The greeting client no longer receives SQL guidelines or tool descriptions — just the schema for the selected tables, the data description, and suggestion-card syntax. A single private build_greeting_client() is the source of truth for both greeter$generate() and the in-app greeting path.
• Constructor tables are always included in the greeting; add_table(include_in_greeting=) / add_tables(include_in_greeting=) opt additional tables in (default off). add_tables accepts a logical/bool or a character vector / list[str] of names.
• Greeting data dicts are scoped to the included tables: per-table entries are filtered, and table-less global dicts keep their description but drop cross-table relationships/glossary, so a curated greeting subset can't leak excluded-table metadata.
• Greetings generate on a separate, throwaway client in every backend (Shiny, Streamlit, Gradio, Dash). The shared qc.greeting is written only by an explicit generate_greeting() / greeter.generate(); in-app greetings stay session-local.

The Python and R implementations mirror each other. generate_greeting() is kept as a thin wrapper over greeter.generate(), so existing callers need no changes.

Verification

Tables passed to the constructor are automatically included in the greeting. Tables added later with add_table() are not included by default — pass include_in_greeting = TRUE to opt them in.

R:

library(querychat)
qc <- QueryChat$new(mtcars, "mtcars")
# Constructor table is included in the greeting automatically
qc$greeter$tables
#> [1] "mtcars"

# add_table() does NOT include the table in the greeting by default
qc$add_table(flights, "flights")
qc$greeter$tables
#> [1] "mtcars"

# ...opt it in explicitly
qc$add_table(airports, "airports", include_in_greeting = TRUE)
qc$greeter$tables
#> [1] "mtcars"   "airports"

greeting <- qc$generate_greeting()  # builds a lean, schema-aware greeting client

Python:

from querychat import QueryChat
qc = QueryChat(data_source=df, table_name="mtcars")
qc.greeter.tables          # ['mtcars'] -- constructor table auto-included

# add_table() does NOT include the table in the greeting by default
qc.add_table(flights, "flights")
qc.greeter.tables          # ['mtcars']

# ...opt it in explicitly
qc.add_table(airports, "airports", include_in_greeting=True)
qc.greeter.tables          # ['mtcars', 'airports']

# add_tables() takes a list of names to include a subset
qc.add_tables(engine, include_in_greeting=["orders", "customers"])

qc.generate_greeting()     # schema-aware greeting on a separate client

Automated checks: make r-check (testthat OK) and make py-check (ruff clean, pyright 0 errors, 616 tests passed), both green.