[api][spark] Treat an unreported partition statistic as unknown, not as zero

[sundapeng]

Purpose

An unreported partition statistic can reach the Spark planner as an exact zero, and a scan over real files then looks free to read.

paimon-api. The statistics are optional in the REST contract, but Partition declares them as primitive long in its @JsonCreator, so Jackson decodes an absent field to 0 and PartitionStatistics.isKnown calls it a measurement. A static @JsonCreator factory now takes them as Long and maps null to UNKNOWN. The public constructor is unchanged, so this is source and binary compatible. totalBuckets and PartitionStatistics stay as they are; the latter travels the other way as a commit delta, where a negative value is a decrement rather than an unmeasured field.

paimon-spark. A catalog that cannot tell "never measured" from "measured, and empty" reports a well formed 0. Since #9351 that becomes the scan row count, and sizeInBytes follows it to zero because the row estimate branch runs whenever numRows is present, leaving the file size fallback unreachable. canBroadcastBySize then passes at any threshold. A reported zero over real bytes is now left unknown and the size is weighed from the files. Only that case changes: zero rows over zero bytes is still an empty scan, and split row counts come from Paimon's own manifests where zero means zero.

Tests

• PartitionTest: absent statistics decode to UNKNOWN, an explicit zero stays exact, a full partition round trips
• CatalogManagedPartitionScanTest: partitions parsed from statistics free JSON keep the plan row count empty
• CatalogManagedPartitionAnalyzeTest: statistics rewritten to zero while the files stay untouched, then the row count comes back unknown and the size above zero. Reverting PaimonStatistics.scala fails that case and no other.
• paimon-api 150 tests, paimon-core 687 tests, CatalogManagedPartitionAnalyzeTest on Spark 3.5 22 tests
• Spotless and checkstyle

[JingsongLi]

+1