[branch-0.9] Cherry pick feat(datafusion): expose PartitionKeysKind getter on IcebergTableScan

[toutane]

Cherry pick 35741b7
Jira https://datadoghq.atlassian.net/browse/QECO-1260

Which issue does this PR close?

• Closes #.

What changes are included in this PR?

Expose to callers which transform family produced an IcebergTableScan's Partitioning::Hash declaration. Today the scan's partitioning surface is opaque: properties().partitioning only carries the Column exprs, so any consumer that needs to branch on "this Hash is identity-backed vs. bucket-backed" has to re-walk the table metadata and re-run the detection logic from bucketing.

Public, re-exported from crate::table:

#[non_exhaustive]
pub enum PartitionKeysKind { Identity, Bucket }
impl IcebergTableScan {
    pub fn partition_keys_kind(&self) -> Option<PartitionKeysKind>;
}

None means the scan declares UnknownPartitioning. Wiring goes through a crate-internal with_partition_keys_kind builder setter on IcebergTableScan, called by IcebergTableProvider::scan right after Partitioning::Hash is chosen. Public constructors (IcebergTableScan::new, new_with_tasks) are unchanged.

• Single source of truth. PartitionKeysKind is derived via PartitionKeys::kind(), i.e. from the same descriptor that drives both task bucketing and the Hash expression list, so kind and Partitioning::Hash cannot drift.
• #[non_exhaustive]. Future transform families (e.g. truncate, mixed) can be added without breaking downstream matches.
• Builder setter rather than a new constructor. Avoids growing the already-wide new_with_tasks signature and keeps the field private.

Are these changes tested?

Existing identity and bucket tests in table/mod.rs extended with partition_keys_kind() assertions on both the Hash and UnknownPartitioning paths.