Fix TruncateTransform.satisfies_order_of crashing on different widths

[SAY-5]

Closes #3680

Rationale for this change

TruncateTransform.satisfies_order_of reads self.source_type (and other.source_type) when the two transforms are not equal, but TruncateTransform.__init__ only sets _width and never sets _source_type. Comparing two truncate transforms of different widths therefore raises AttributeError: 'TruncateTransform' object has no attribute '_source_type' instead of returning a boolean, because same-width comparisons only work by taking the early self == other return. Two truncate transforms are ordered by width, so the comparison can be decided from the widths alone.

Are these changes tested?

Yes. Added test_truncate_satisfies_order_of_different_widths and confirmed the existing transform tests still pass (pytest tests/test_transforms.py -k "truncate or satisfies_order"). The two test_truncate_pyarrow_transforms cases that fail locally require the optional pyiceberg-core extra and are unrelated to this change.

Are there any user-facing changes?

No.

[Sanjays2402]

dropping the source_type check means an int/long/decimal transform now satisfies_order_of another purely on width. is that the intended widening, or should it stay type-gated? the java implementation only returns true within the same type family, so one type family claiming to satisfy another (string vs int) could let an invalid sort-order replacement through.

[SAY-5]

Good question. The _source_type PrivateAttr on TruncateTransform is never assigned anywhere in the codebase, so self.source_type raises AttributeError on any non-equal comparison, which is the crash this PR fixes (#3680). That means the previous StringType branch never actually ran for a bare TruncateTransform(n) either.

For the widening concern: satisfies_order_of is only meaningful when both transforms are bound to the same source field (same sort key), so they already share a type family by construction; a truncate transform carries no independent source type to cross-compare. This also matches the sibling transforms in this file, e.g. the time transforms compare purely on granularity and BucketTransform on num_buckets, without re-checking the source type. The added test asserts a non-truncate (BucketTransform) returns False, so cross-transform mixing is still rejected. Happy to add an explicit same-family guard if you'd prefer it spelled out.