feat: add rename_column support for ALTER TABLE

Adds RenameColumn as a terminal operation in the ALTER TABLE framework:
- Renaming type state ensures rename cannot be combined with other operations
- Buildable trait + sealed module for shared build() between Modifying and Renaming
- Case-insensitive sibling conflict check via sibling_names_at_path
- Physical identity (column ID + physical name) preserved via with_name
- Runtime defense-in-depth: RenameColumn must be the sole operation

Full integration test suite covering add/drop/rename/set_nullable, chaining,
sequential alters, checkpoints, time travel, and append-only tables.

Author: william-ch-databricks

kernel/src/transaction/alter_table.rs

@@ -4,6 +4,8 @@
 //! [`try_new_alter_table`](AlterTableTransaction::try_new_alter_table) constructor.
 //! The builder logic lives in [`builder::alter_table`](super::builder::alter_table).
 
+// Allow `pub` items -- module visibility controls external access; items are `pub` for
+// use within the crate and for tests.
 #![allow(unreachable_pub)]
 
 use std::marker::PhantomData;

kernel/src/transaction/builder/alter_table.rs

@@ -7,8 +7,9 @@
 //!
 //! - [`Ready`]: Initial state. Operations are available, but `build()` is not (at least one
 //!   operation is required).
-//! - [`Modifying`]: After at least one operation (`add_column`, `set_nullable`). Can chain more
-//!   operations, and `build()` is available.
+//! - [`Modifying`]: After `add_column`, `drop_column`, or `set_nullable`. These can be chained,
+//!   and `build()` is available.
+//! - [`Renaming`]: After `rename_column`. Only `build()` is available (rename is terminal).
 
 use std::marker::PhantomData;
 use std::sync::Arc;
@@ -31,6 +32,9 @@ pub struct Ready;
 /// State after at least one operation has been added. `add_column` and `build()` are available.
 pub struct Modifying;
 
+/// State after rename_column. Only `build()` is available (rename is terminal).
+pub struct Renaming;
+
 /// Builder for constructing an [`AlterTableTransaction`] with schema evolution operations.
 ///
 /// Uses a type-state pattern to enforce valid operation chaining at compile time.
@@ -107,6 +111,30 @@ impl AlterTableTransactionBuilder<Ready> {
         self.operations.push(SchemaOperation::SetNullable { path });
         self.transition()
     }
+
+    /// Rename a column in the table schema. Supports nested columns via [`ColumnName`] paths.
+    ///
+    /// Requires column mapping mode = name or id. Only the logical name changes; the physical
+    /// name and column ID remain the same.
+    ///
+    /// Rename is a terminal operation -- no further operations can be chained.
+    ///
+    /// # Errors (at build time)
+    ///
+    /// - Column does not exist
+    /// - Column mapping mode is not enabled
+    /// - New name conflicts with an existing column at the same level
+    pub fn rename_column(
+        mut self,
+        path: ColumnName,
+        new_name: impl Into<String>,
+    ) -> AlterTableTransactionBuilder<Renaming> {
+        self.operations.push(SchemaOperation::RenameColumn {
+            path,
+            new_name: new_name.into(),
+        });
+        self.transition()
+    }
 }
 
 impl AlterTableTransactionBuilder<Modifying> {
@@ -127,7 +155,21 @@ impl AlterTableTransactionBuilder<Modifying> {
         self.operations.push(SchemaOperation::SetNullable { path });
         self
     }
+}
+
+/// Marker trait for builder states that support `build()`. Sealed to prevent external impls.
+pub trait Buildable: sealed::Sealed {}
+impl Buildable for Modifying {}
+impl Buildable for Renaming {}
+
+mod sealed {
+    /// Prevents external implementations of [`Buildable`](super::Buildable).
+    pub trait Sealed {}
+    impl Sealed for super::Modifying {}
+    impl Sealed for super::Renaming {}
+}
 
+impl<S: Buildable> AlterTableTransactionBuilder<S> {
     /// Validate and apply schema operations, then build the [`AlterTableTransaction`].
     ///
     /// This method:

kernel/src/transaction/mod.rs

@@ -445,10 +445,9 @@ impl<S> Transaction<S> {
         let remove_actions =
             self.generate_remove_actions(engine, self.remove_files_metadata.iter(), &[])?;
 
-        // Build the action chain
-        // For create-table: CommitInfo -> Protocol -> Metadata -> adds -> txns -> domain_metadata
-        // -> removes For existing table: CommitInfo -> adds -> txns -> domain_metadata ->
-        // removes
+        // Build the action chain:
+        // CommitInfo -> Protocol (if emitted) -> Metadata (if emitted) -> adds -> txns ->
+        // domain_metadata -> removes
         let actions = iter::once(commit_info_action)
             .chain(protocol_action.map(Ok))
             .chain(metadata_action.map(Ok))
@@ -740,6 +739,11 @@ impl<S> Transaction<S> {
         // must be the larger of:
         // - The time at which the writer attempted the commit
         // - One millisecond later than the previous commit's inCommitTimestamp
+        //
+        // TODO: When ALTER TABLE supports enabling ICT for the first time, the read snapshot
+        // won't have a prior ICT. In that case we should fall back to self.commit_timestamp
+        // (same as CREATE TABLE). Currently protocol evolution is out of scope so this path
+        // is not reachable.
         Ok(self
             .read_snapshot()?
             .get_in_commit_timestamp(engine)?