[kvlonge]

Why

A code location re-reads every warehouse state table on each sync, even when nothing has changed. On Snowflake each read resumes the warehouse, so an idle project pays for compute on every sync.

Changes

• Adapters can report a per-table change token through an optional RelationChangeTokenReader protocol. Snowflake uses SYSTEM$LAST_CHANGE_COMMIT_TIME, which cloud services answer without resuming the warehouse.
• Before a scan's first page, the native host reads the token. When it matches the token from the last complete read of that table, it returns an unchanged page and reads no rows.
• The CLI keeps tokens in memory, recorded only when a scan completes. A reconciling scan skips only on a token recorded by a reconciling read, and a scan never skips when the mirror lost rows that the recorded read had.
• Adapters without the capability, missing tables and token errors read as before.
• The server docs say a Snowflake sync with nothing new doesn't resume the warehouse.

No DuckShop case applies: this changes how the location reads state tables during sync, not a project shape, data value or build lifecycle.

Verification

• Rust cases for when a recorded token may skip, including a regression case that fails without the incremental-read guard.
• E2E: a served DuckDB location with a token hook reads nothing when tokens are unchanged, only the changed table after a write, and re-reads a table whose mirror rows were deleted.
• Existing automatic-history and incremental-overlap E2E tests pass.
• Live Snowflake check: an unchanged sync left the warehouse suspended; after one inserted row the sync resumed it.
• make check-ci passes.