[SPARK-52246][SQL][TESTS] Add bucket transform regression test for one-side shuffle with join key tail of partition keys

[naveenp2708]

What changes were proposed in this pull request?

Add a regression test to KeyGroupedPartitioningSuite for the scenario reported in SPARK-52246 (test adapted from the reproduction in the JIRA description): a storage-partitioned join where one side is auto-shuffled, the partitioned side uses a bucket transform, and the partition key is the tail of the join keys.

Why are the changes needed?

SPARK-52246 reported silent incorrect results (empty join output) for this scenario on 4.0.0/4.0.1. The defect was fixed by SPARK-54439, but the tests added there cover identity and years transforms only, not bucket. This locks in coverage for the bucket case.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

New test passes on master; verified it fails on v4.0.1 (pre-SPARK-54439), reproducing the original wrong results.

Was this patch authored or co-authored using generative AI tooling?

No.

[naveenp2708]

@peter-toth I’ve added the regression test discussed in the JIRA. Could you please take a look when you have a chance?

[uros-b]

Thank you @naveenp2708!

[peter-toth]

Thanks for the PR, @naveenp2708!

I traced this independently: it adds the bucket variant of the "one side auto-shuffled, partition key is the tail of the join keys" case from SPARK-52246 (the wrong-partitioning-function bug that gave empty join output, fixed under SPARK-54439). The two SPARK-54439 tests only cover identity and years, so this fills the bucket gap. Checks I ran: the only join match is items (1,'aa',40.0,2020-01-01) with purchases (1,42.0,2020-01-01), so the expected Row(1, "aa", 40.0, 42.0) is right; it uses the current config name V2_BUCKETING_ALLOW_KEYS_SUBSET_OF_PARTITION_KEYS (the JIRA repro's ...ALLOW_JOIN_KEYS... was renamed); the confs and the shuffles.size == 1 SPJ assertion match the sibling tests; CI is green. No blocking or non-blocking findings from me.