feat(transaction): support transform-based sort orders

[viirya]

What changes are included in this PR?

ReplaceSortOrderAction only supported sorting by a column's raw value (an implicit identity transform) — asc/desc hardcoded Transform::Identity and only accepted a column name. There was no way to declare a sort order using a transform (bucket[N], year, truncate[W], etc.), which Java's SortOrderBuilder.asc/desc(Term, NullOrder) supports.

Adds asc_with_transform / desc_with_transform:

tx.replace_sort_order()
    .asc_with_transform("event_time", Transform::Year, NullOrder::First)
    .desc_with_transform("id", Transform::Bucket(16), NullOrder::Last);

asc/desc are unchanged (same signature, same behavior) — they now delegate to the new methods with Transform::Identity, so no existing caller is affected.

Whether a transform is valid for the source column's type is checked at commit time (via the existing SortOrder::builder().build(schema) → check_compatibility), matching the timing of Java's SortOrder.Builder.build() — an incompatible transform is only rejected once the table schema is available, not at the asc_with_transform call site.

Scope

This only extends the metadata-declaration API — which sort order (including which transform) can be recorded on a table. Whether the write path actually sorts a RecordBatch to match a table's declared sort order is a separate, pre-existing gap: no writer in crates/iceberg/src/writer/ reads SortOrder or sorts data today, for any sort order, including the pre-existing identity case. This PR does not touch that; it only makes a wider set of sort orders declarable.

Are these changes tested?

• test_replace_sort_order_with_transform — the builder records the requested transform per field.
• test_replace_sort_order_with_transform_commits — end-to-end commit; the resulting TableUpdate::AddSortOrder's SortField carries the requested transform.
• test_replace_sort_order_rejects_incompatible_transform — Transform::Year on a long column is rejected at commit time with ErrorKind::Unexpected, exercising the existing check_compatibility path.
• Existing test_replace_sort_order (plain asc/desc) passes unchanged.

Full iceberg lib suite passes; clippy and rustfmt clean.

[NikitaMatskevich]

Can we also add an integration test that would write a metadata.json with updated sort order, and then another operation would read this json and correctly parse the transform?

[viirya]

Good idea — added in eee40b8: test_sort_order_transform_survives_metadata_json_round_trip.

It commits a transform-based sort order (bucket[16] asc + truncate[4] desc) through the in-crate memory catalog, which serializes the updated table metadata to an actual metadata.json file (TableMetadata::write_to on FileIO), then reloads the table via catalog.load_table — which reads and parses that file back (TableMetadata::read_from) — and asserts both transforms and directions survive. So the transform string ("bucket[16]" etc.) is exercised through the real serialize-file-parse path, not just the in-memory TableUpdate.

[huan233usc]

LGTM

[viirya]

@CTTY Could you take a look at this? Thanks!