Parse unrecognized transform names as Transform::Unknown

[moomindani]

Which issue does this PR close?

• Part of Unrecognized transform names fail parsing instead of becoming Transform::Unknown #2789 (the non-breaking subset; preserving the original transform name for round-trip needs a Transform::Unknown(String) API discussion and stays tracked there).

What changes are included in this PR?

The V3 spec requires readers to read tables with unknown transforms, ignoring them. FromStr for Transform returned an error for any unrecognized transform name, so loading table metadata that uses a transform iceberg-rust does not know failed entirely.

This changes parsing to match Java's Transforms.fromString: a string that is not an exactly well-formed known transform parses as Transform::Unknown instead of erroring. This covers unknown names (zorder), names sharing a prefix with known transforms (bucketv2[4]), malformed parameter shapes (bucket[abc], bare bucket), and loose forms the previous parser accepted by accident (bucket10, previously parsed as Bucket(10)). Well-formed parameters that overflow u32 still error, matching Java's behavior for the equivalent input.

Interaction with #2474 noted: that PR tightens parameter validation of known transforms; the two changes are semantically compatible (well-formed known-transform parameters are validated, everything else is unknown).

This is the Rust counterpart of the behavior proposed for PyIceberg in apache/iceberg-python#3630.

Are these changes tested?

Yes — new unit tests in spec/transform.rs: known-transform parsing, the unknown fallback across nine unknown/malformed inputs, and the overflow error case. cargo test -p iceberg --lib spec::transform, cargo fmt --check, and cargo clippy -p iceberg --lib pass locally.

This pull request and its description were written by Claude Fable 5.

[moomindani]

Gentle ping — this has been open for ~3 weeks with CI green and no review yet.

It's a small, self-contained change: FromStr for Transform currently errors on any unrecognized transform name, but the v3 spec requires readers to read tables with unknown transforms and ignore them, so a table using a transform this version doesn't know about is unreadable today. One file, spec/transform.rs.

Scoped deliberately to the non-breaking subset — preserving the original name for round-trip needs a Transform::Unknown(String) API discussion, which stays in #2789.

@blackmwk you've reviewed most of the recent spec changes — would you mind taking a look when you have a moment? Part of #2411.

[moomindani]

Rebased onto current main — this had drifted 85 commits behind and was conflicting, so no CI had run on it for weeks. Now mergeable and green.

Verified locally with the pinned toolchain: cargo test -p iceberg --lib 1750 passed, cargo clippy --all-targets --all-features -- -D warnings clean, cargo fmt --check clean. The rebase conflict was only in the test module, where main and this branch had each appended tests at the same place; both sets are kept.

@CTTY @kevinjqliu this is a small spec-conformance fix — v3 readers are required to read tables with unknown transforms rather than fail parsing, matching Java's Transforms.fromString. It has had no review since it was opened on 9 July. Would either of you take a look?

[github-actions]

This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions.

[moomindani]

Not stale. Rebased onto current main again to clear a conflict with the invalid_data! macro from #2928; the parameter-parsing helper now uses it too. cargo test -p iceberg --lib 1978 passed, clippy and fmt clean, public API unchanged.

@laskoviymishka you reviewed and merged the recent spec/transform.rs changes (#2928, #3243); would you take a look? It is one file.