[WIP][ML] Avoid per-leaf map for tree predictions

[zhengruifeng]

What changes were proposed in this pull request?

Replace the transient Map[LeafNode, Int] used by tree leaf prediction with a normal integer
field on each LeafNode. Tree-model construction assigns the same left-to-right DFS indices
after training and loading, so prediction only traverses the tree and reads the reached leaf's
stored ID. The existing NodeData format deliberately omits this field, while broadcast
serialization retains it.

Why are the changes needed?

Large trees can have many leaves. When leaf prediction is used, the map creates a hash-table
entry and boxed value for every leaf in each executor's model copy. A single integer per leaf
keeps the lookup constant-time while substantially reducing the memory overhead and avoids
building an executor-side lookup cache.

Does this PR introduce any user-facing change?

No. Leaf IDs and their traversal order are unchanged.

How was this patch tested?

Added persistence assertions that verify classifier and regressor leaf IDs are unchanged after
loading. Tests have not been run yet; the relevant ML suites will be run before this draft is
marked ready for review.

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

Generated-by: Codex (GPT-5)

[zhengruifeng]

Memory estimate for the leaf-prediction path (measured with JOL on Java 11 / Scala 2.13, with compressed references):

Leaves	Old Scala map cache	Stored leafIndex fields	Net saved
1,000	52,480 B	8,000 B	44,480 B
10,000	464,280 B	80,000 B	384,280 B
100,000	5,302,184 B	800,000 B	4,502,184 B

This is approximately 40-45 bytes per leaf, or 40-45 MiB for one million leaves, on this JVM. The actual number will vary with JVM and Scala collection implementation.

The normal Int field adds about 8 B per leaf even when leaf prediction is unused; the net saving above applies when predictLeaf would otherwise construct the map.