[core] Prune manifests by bucket metadata

[jianguotian]

Purpose

Bucket-key point lookups spanning many partitions can spend most of their time opening manifests whose bucket ranges cannot match. Manifest metadata currently lacks total-bucket bounds, and existing compacted manifests cannot be reorganized under an opt-in bucket-first layout.

This supersedes #9783 with a clean, single-commit branch based on the latest master.

Changes

• persist nullable min/max bucket-count metadata in manifest lists
• prune manifests conservatively with bucket and total-bucket ranges
• push partition/bucket filters into projected delete-entry reads
• add an opt-in bucket-first manifest sort order
• add a one-shot forced manifest rewrite option for maintenance
• expose the new ranges in the manifests system table
• fall back to partition-only manifest comparison for a whole compaction pass when legacy bucket bounds are missing, preserving comparator transitivity
• reject manifest-sort.bucket-first for data evolution tables instead of silently ignoring it
• make manifest compact dry-run honor the bucket-first option

Legacy manifests without the new nullable fields fall back to conservative reads. Both new options default to false. Bucket enumeration is bounded and also falls back conservatively.

Performance evidence

On a production-shaped 2.54 TB test branch using the same point-lookup SQL and result set, the combined layout and pruning path reduced opened manifests from 136 to 1 and planning from 22.6 s to 2.0 s. Resulted data files remained 54 and splits remained 25, isolating the change to planning rather than data scanning.

Verification

• focused paimon-core tests: 152 tests, 0 failures, 0 errors, 1 skipped
• paimon-core plus required modules package: BUILD SUCCESS (9 modules)
• Checkstyle, Spotless, and Maven Enforcer: BUILD SUCCESS
• generated core option documentation updated

[JingsongLi]

Please narrow this PR to manifest bucket pruning and complete that independently first. Manifest sorting, bucket-first layout, forced manifest rewrites, and other independent optimizations should be separate follow-up PRs.

For the pruning metadata, I suggest a single nullable totalBuckets instead of minTotalBuckets / maxTotalBuckets:

• Record N only when every ADD and DELETE entry in the manifest has the same positive total bucket count.
• Record null for mixed or non-positive counts. Legacy metadata and copied manifests with unknown statistics must also remain unknown.
• Keep the existing minBucket / maxBucket. When N is known and the predicate determines candidate buckets, reuse BucketSelector's existing bucket-set cache for N and check whether any candidate falls within that range.
• When the required metadata or predicate information is unavailable, or the manifest contains negative buckets, conservatively retain the manifest and continue the existing entry filtering.

This removes total-bucket-count range enumeration and its combination limits. The tradeoff is deliberately narrower pruning coverage: manifests containing different bucket counts will fall back. Different partitions can retain different counts, so we must not substitute the current table's bucket option for this metadata.

Let's implement and evaluate this simpler pruning change on its own first, without changing manifest sort behavior in the same PR. More general mixed-count pruning and layout changes can be considered separately with their own performance evidence.