[kvlonge]

Why

A code location's background metadata sync woke a suspended Snowflake warehouse every cycle, even when nothing had changed. The catalog page listed relations and columns through information_schema.tables and information_schema.columns, and every Snowflake connection checked its session schema through information_schema.schemata. All three need a running warehouse, so the warehouse never stayed suspended.

Changes

• When an adapter provides schema-scoped listings, the catalog page reads them, matching what the build already uses. Today that is Snowflake, which lists with SHOW TABLES, SHOW VIEWS and SHOW COLUMNS IN SCHEMA. Columns are matched by stored name. Other adapters read the catalog as before.
• Snowflake schema_exists uses SHOW SCHEMAS LIKE … IN DATABASE and matches the name exactly, ignoring case. A missing database means the schema does not exist. With no known database, or a name containing a backslash, it keeps the information-schema query.
• Unit tests cover a mixed-case schema, a LIKE wildcard neighbour, a missing database and the backslash fallback.

Not covered here:

• CI has no Snowflake, so the schema-scoped catalog branch is verified live, not by a test. The DuckDB and SQLite catalog tests cover the unchanged branch.
• A schema over the 10,000-row SHOW COLUMNS cap still falls back to information_schema, which needs a running warehouse.

DuckShop edge case: not applicable. This is adapter metadata reading.

Verification

• Snowflake unit tests and the catalog integration tests pass.
• Live Snowflake check, X-Small warehouse, 63 relations: relation names, types and columns were identical to the old path for every relation.
• With this change and the two statistics fixes, I suspended the warehouse and sampled it every 10 s through two complete sync cycles. It stayed suspended throughout. The only other read, of fingerprints, was answered from cache.
• make check-ci: passes.

[kvlonge]

Folded into #1419 so the location sync fixes share one CI run. The branch is kept.