Remove insert-vs-alter transaction conflict check

[fuziontech]

Summary

• Remove the overly conservative conflict check that prevents concurrent INSERT and ALTER TABLE operations on the same table
• Add test covering concurrent INSERT + ADD COLUMN, INSERT + RENAME COLUMN scenarios

Problem

Tools like sqlmesh perform schema evolution (ALTER TABLE ADD COLUMN, RENAME COLUMN) as part of model materialization while concurrent data pipelines INSERT into the same tables. This causes:

Transaction conflict - attempting to insert into table with index "25667"
- but another transaction has altered it

DuckLake retries internally (up to 100 times) but the conflict is permanent because the check always compares against the transaction's original snapshot.

Why this is safe

Each data file carries its own mapping_id (stored in ducklake_data_file) that describes the column layout at write time. The DuckLakeMultiFileReader::CreateMapping function looks up the file's mapping and creates the correct column mapping for that specific file, regardless of the current table schema.

When an INSERT commits after an ALTER:

1. The INSERT's data files have a mapping_id describing the pre-ALTER schema
2. The reader uses this mapping to correctly read the file (missing columns → NULL)
3. The ducklake_column_mapping and ducklake_name_mapping tables preserve the mapping
4. Schema versioning in ducklake_schema_versions tracks which version applies at each snapshot

The insert-vs-drop conflict check is preserved since a dropped table is genuinely gone.

Test plan

• New test transaction_insert_alter_no_conflict.test covering:
  • Concurrent INSERT + ADD COLUMN (both orderings)
  • Concurrent INSERT + RENAME COLUMN
  • Verification that data is readable with correct values after concurrent operations
• Existing transaction conflict tests still pass (DROP, CREATE same name, etc.)

🤖 Generated with Claude Code