[AI] Fix Iceberg CTAS prepared rebind

[dataders]

Important

this patch was created by me, a human, and I heavily leaned on LLM agents. That said, it actually fixes the bug for me. My intent in opening this was predominately to unblock the integration of duckdb-iceberg into the dbt Fusion engine. Any feedback here is more than welcome!

Summary

• avoid Iceberg CTAS catalog side effects during prepare-only planning
• force prepared CTAS to rebind at execution, where the table should actually be created
• keep normal duplicate CTAS behavior intact with a regression test

Resolves: dbt-labs/dbt-core#13621
related: dbt-labs/dbt-core#14547
related: duckdb/dbt-duckdb#725

Why this still seems right

the likely shape was described on #595 (comment): prepare and execute can both try to create the Iceberg table when staged create handling does not protect the flow.

That matches the clean repro. The table does not exist before duckdb_prepare. Published Iceberg creates it during prepare. Then duckdb_execute_prepared_streaming rebinds/replans and hits create again.

I also tried the same repro with SUPPORT_STAGE_CREATE true. Published 1.4.4 still fails with Table ... already exists; published 1.5.2 still fails with the optional-pointer internal error.

This patch makes Iceberg CTAS prepare side-effect free and marks the prepared statement as needing execution-time rebind.

Repro

• full Python/C-API repro is on issue [BUG] Fusion does not respect columns defined under versions dbt-labs/dbt-core#13621: CREATE TABLE fails when Iceberg is accessed from Adbc #595 (comment)
• pure SQL is not enough here because DuckDB SQL rejects PREPARE ctas AS CREATE TABLE ... AS ...
• DuckDB 1.4.4 + published Iceberg fails with Table ctas_prepare_rebind_595_<uuid> already exists
• DuckDB 1.5.2 + published Iceberg still fails, now with INTERNAL Error: Attempting to dereference an optional pointer that is not set
• patched branch succeeds with the same prepare/execute shape

Testing

• cmake --build build/debug --target libduckdb.dylib iceberg.duckdb_extension duckdb_local_extension_repo
• uv run python3 -m py_compile test/python/test_prepared_ctas.py
• uv run --with pytest --with pyspark==3.5.2 python3 -m pytest test/python/test_prepared_ctas.py -q (local no-catalog path: 2 skipped)
• clean repro against official DuckDB 1.4.4 and 1.5.2 dylibs
• patched debug build against Lakekeeper using duckdb_prepare + duckdb_execute_prepared_streaming
• jaffle-sandbox dbt run --target iceberg_rest --select iceberg_rest_catalog_demo, plus DuckDB readback count=1

[Tmonster]

Hi @dataders,

Thanks for looking into this! I'm looking through it and it seems reasonable to me. I will chat with some people on core first to make sure this is the right approach before merging. Hopefully we can get this in for v1.5.3

[dataders]

thanks @Tmonster! for the record, I feel guilty and "part of the problem" to be slinging slop your way, so thanks for your understanding. Hope this PR is more helpful to you than harmful

at the very least the repro I added to the issue is instructive

[Tmonster]

Hi @dataders ,

Took a look and I think #974 provides a cleaner solution. I have included your test to make sure it also handles the prepare/execute path as well