APPROVE with a few small suggestions.

Clean, well-scoped addition of transaction_mode = none | snapshot on top of #6623. Default is none (non-breaking); serde round-trip is covered by the two new unit tests; two new integration tests exercise the unordered and ordered transactional paths. Commit is signed off with no AI trailers, checklist notes explicitly that input-buffer staging is deferred to the FT queue work — nice, honest scoping.

A few things to consider (all non-blocking):

• Option<Option<String>> is misleading. The outer Option means "is this call transactional", the inner Option<String> is the label — but you always construct it as Some(Some(format!("snapshot-{index}"))), so the inner Option never carries None. Either fold it to Option<String> (None = no transaction, Some = transactional with a label) or introduce a small enum (Transactional::No / Yes(Option<String>)) if you want to preserve the "labeled or unlabeled transaction" distinction for future modes. As written, readers will assume the inner None case exists.

• Ordering::AcqRel on transaction_index is stronger than needed. The counter only feeds the human-readable snapshot-{index} label — no other state is synchronized through it. Ordering::Relaxed is the right default for pure counters; leaving AcqRel invites future readers to assume it establishes happens-before with something.

• Docs. The PR checklist has "Documentation updated" unchecked. transaction_mode is now a public YAML option; please add a short entry to the Iceberg connector docs (behavior with/without timestamp_column, and that non-transactional is the default). Feldera's connector reference is where users will look for this.

• Retry + commit interaction. In execute_df, if all max_retries attempts fail, we bail without pushing a commit entry — leaving the started transaction (from the first flushed entry of the failed attempts) dangling on the queue. And on the successful retry path, the previous attempts have already push_entry'd rows into the queue (that's pre-existing behavior from #6623), so a snapshot transaction spanning several retry attempts can include re-flushed rows from earlier failed attempts. Neither is new in this PR, but making the whole thing a transaction now makes the semantics user-visible. Worth a comment near the retry loop describing the intended behavior on partial failure — and, if feasible in a follow-up, aborting the started transaction on terminal failure rather than leaving it open.

This looks surprisingly simple, but there may be subtleties which escape me

Looks good. Before creating more PRs for the iceberg connector, let's make sure we have some integration tests. Also, let's start on iceberg QA workloads.