feat(paimon-core): Add test cases for TableScan partition, bucket, level filters and list APIs

[fightBoxing]

Re-created from closed PR #7214.

Summary

Add comprehensive test cases for TableScan in paimon-core to improve coverage for InnerTableScan interface methods.

Changes

• Add testPartitionFilter: Test partition filter with Map and BinaryRow
• Add testBucketFilter: Test withBucket and withBucketFilter methods
• Add testLevelFilter: Test level filter for primary key table
• Add testListPartitionEntries: Test listPartitionEntries and listPartitions APIs
• Add testPrimaryKeyTableScan: Test scan with update and delete operations
• Add testEmptyTableScan: Test scan behavior on empty table
• Add testScanWithMultipleFilters: Test combination of partition and column filters
• Add testLimitWithPartitionFilter: Test limit pushdown with partition filter
• Add testScanAfterCompaction: Test scan result after compaction
• Add testTopNWithPartitionFilter: Test TopN with partition filter combination

API Coverage

• withPartitionFilter, withBucket, withBucketFilter, withLevelFilter
• listPartitionEntries, listPartitions

Closes #7214

[JingsongLi]

Reviewed 498db17. Requirement fit: UNSUPPORTED for this broad coverage-only scope. Implementation: FINDINGS in the added tests.

I am closing this version because the added maintenance surface is not justified by additional end-to-end regression protection. Existing tests already cover partition listing (TableScanListPartitionsTest), bucket filtering (SimpleTableTestBase), partition filtering and TopN. The new TopN case checks only splits.size() <= 2 without checking either returned rows or partition membership; returning no data passes it. Several bucket/level/filter assertions likewise accept an empty result, and testScanAfterCompaction does not establish that a compaction occurred.

The exact-head Maven reactor/package run on JDK 11 completed the TableScanTest suite: 20 tests, 2 failures, both in newly added methods. testBucketFilter assumes ten committed rows mean ten splits, but the planner produces three bucket splits. testScanWithMultipleFilters reads a=10 even though its assertion requires a>=50: scan pruning is not an exact row filter, and the TableRead was not configured with the predicate.

Please replace this broad addition with a focused test PR for a specific missing contract or real regression: assert the exact expected rows/files, prove the intended optimization or compaction ran, and show a representative faulty implementation fails the test. That would change the value assessment; simply increasing API coverage or test count does not.