[kvlonge]

Why

A code location's metadata sync kept a suspended Snowflake warehouse running and could loop forever on slow statistics reads. It also mirrored only 7 of the 10 state tables SQLBuild writes. This combines three fixes so they share one CI run. Each was reviewed and passed checks on its own.

Changes

• Statistics paging: statistics pages have their own statistics_limit, which halves after a failed read and survives the rewind through catalog. A page too large to deliver halves the current kind's limit.
• Snowflake without a running warehouse: the catalog page uses the adapter's schema-scoped listings (SHOW TABLES, SHOW VIEWS, SHOW COLUMNS IN SCHEMA). schema_exists uses SHOW SCHEMAS LIKE … IN DATABASE with an exact, case-insensitive match. Other adapters are unchanged.
• All state tables: new sync kinds column_migrations, node_results and consumption. A test fails if a name in STATE_TABLE_NAMES has no kind. Rows without an event ID get one derived from their identity columns.
• Fix: state tables without event_id can now be paged on Snowflake and SQL Server.
• warehouse_metadata/main is split into ingest, location-read and person-read modules.
• New control-store tables: as with every pre-release schema change, existing control stores must be recreated.

DuckShop: new state-table fixtures. The paging and adapter-listing changes are not project shapes.

Verification

• Combined branch: 52 warehouse metadata, catalog and statistics integration tests pass, and make check-ci passes.
• Before combining: 127 orchestration tests on SQLite and PostgreSQL, the CLI location_metadata tests, and the Snowflake unit tests.
• Live Snowflake X-Small check with all three changes: three full sync cycles of all 12 kinds ran with the warehouse suspended throughout. The first statistics sync completed at a page size of 25, after timeouts at 100 and 50.

[kvlonge]

Correction to the description above, where "without waking a suspended warehouse" overstates what this PR does.

• Only the catalog and statistics reads avoid the warehouse. They use SHOW TABLES, SHOW VIEWS, SHOW COLUMNS IN SCHEMA, SHOW SCHEMAS and SHOW OBJECTS, which run in cloud services.
• State-table reads can resume it. All ten state-table sync kinds work the same way. The sync connects with the target's warehouse (USE WAREHOUSE) and checks the table with SHOW. It then runs SELECT … FROM <state table> WHERE <keyset cursor> [AND <timestamp> >= <watermark>] ORDER BY … LIMIT n. With auto-resume on, any such SELECT that Snowflake's result cache can't answer resumes the warehouse. A new watermark or cursor changes the query text, and so does new state. Nothing checks whether a table changed before its SELECT runs.
• What the live X-Small check proved: with an unchanged store and repeated query text, three sync cycles left the warehouse suspended, because the state-table SELECTs came from the result cache.
• What it didn't prove: syncing new state without a resume. The same session resumed the warehouse twice on the first, uncached consumption reads. Only two state tables held rows, and nothing wrote new state during the quiet window. The check sampled SHOW WAREHOUSES about a minute apart and read no warehouse event or metering history.

A follow-up will skip each state-table SELECT when the table's last-altered time hasn't moved since the last sync. It will verify both cases, no new state and new state, with warehouse event and metering history.