CDC table functions resolve the table at the current snapshot, not the queried window

[shefeek-jinnah]

Surfaced by an automated multi-agent correctness audit; verified against the code.

Summary

The CDC table functions (ducklake_table_changes, ducklake_table_deletions, ducklake_table_insertions) resolve the target schema/table at the catalog's current latest snapshot rather than at the queried CDC window, so a table that has since been dropped/renamed cannot be queried even for a window entirely within its valid lifetime.

Location

• src/table_functions.rs:271-272 — parse_cdc_args calls provider.get_current_snapshot() and then get_schema_by_name / get_table_by_name at that snapshot, after start_snapshot/end_snapshot were already resolved.

Failure scenario

Create table t at snapshot 1, modify at 2, drop at 3; catalog later advances to snapshot 10 via unrelated activity. ducklake_table_changes('main.t', 1, 2) — a valid historical query — fails with Table 'main.t' not found in catalog, because resolution uses snapshot 10 instead of the window.

Suggested fix

Resolve the schema/table using the window's end_snapshot (or start_snapshot, per intended semantics) rather than get_current_snapshot().

Severity: High (legitimate historical CDC queries on dropped/renamed tables hard-error).