6.2.0 — schema-qualified table names and a checked schema qualifier

Tables with the same name in different schemas can be described and
queried, and a query's schema is now checked against the allowlist.

Fixed

• schema.yaml table keys may name their schema (PR #133). A key may be qualified, such as sales.Customer or OtherDb.dbo.Customer; brackets are allowed. This is what lets sales.Customer and ref.Customer both be described. Before, a qualified key never matched a query, so every query on it was refused as an unknown table.
• An ambiguous table name is refused with the fix named (PR #133). FROM Customer, when two schemas have a Customer, is refused with the new guard reason ambiguous_table. The message names the references to use, so the model's retry corrects it, and the web UI explains it in Persian.
• The prompt shows how to reference a shared name (PR #133). Such tables get a Reference as: [sales].[Customer] line. Prompts for schemas with unique names are unchanged.

Security

• A query's schema is checked, not ignored (PR #133). Before, the guard matched tables by bare name only, so with Customer allowlisted in sales, a query on [hr].[Customer] passed and read a table that is not allowlisted. An explicitly qualified reference must now match the table's known schema. A table with no known schema (a bare key without db_schema) still accepts any schema, because there is nothing to check it against.

Upgrading

• No action needed for a schema.yaml with unique table names. A generated query that names the wrong schema is now refused, and the model's retry corrects it.
• If the same table name exists in several schemas, key each one with its schema, such as sales.Customer: and ref.Customer:.
• Set db_schema on every bare-keyed table. Without it, that table's schema cannot be checked. See docs/design/TABLE-NAMES.md.