Core: Simplify list handling in manifest read and write paths

[uros-b]

Two small, behavior-preserving cleanups to how manifest code builds result lists:

• ManifestsTable#partitionSummariesToRows — the rows list is filled with exactly one row per entry in summaries, a size known up front, so it is allocated with Lists.newArrayListWithCapacity(summaries.size()) instead of the default-capacity newArrayList(), avoiding intermediate resizes.

• ManifestFiles#writeParallel — replaced the intermediate List<Pair<Integer, List<F>>> (built only to carry each group's index) with Tasks.range(groups.size()) indexing directly into groups. This drops the list, its build loop, one Pair allocation per group, the now-unused Pair import, and the comment that existed only to explain the pairing, and it makes the input-order guarantee visible in the run body. It also brings the method in line with the Tasks.range(n) idiom used by every other parallel fan-out in the codebase (ManifestMergeManager, ManifestFilterManager, SnapshotProducer, DVUtil, and the Spark/Flink planners); writeParallel was the sole outlier, having diverged when it was extracted from SnapshotProducer in Core: extract parallel manifest write logic out of SnapshotProducer #16730. The AtomicReferenceArray results assembly is unchanged.

The ManifestsTable pre-size is intentionally limited to this one spot rather than a codebase-wide sweep of every under-sized list, to keep the change small and easy to review.

[ebyhr]

Looks good to me, but there are still same patterns in other places.

[uros-b]

Thank you @ebyhr. Yeah, probably there are other places too, but I happened to come across this one. Otherwise, the PR could explode quite a bit (like this one for example: #17534).

[anoopj]

LGTM

[ebyhr]

Limiting the scope is perfectly acceptable, but I recommend providing an explanation of the intention in the PR description. This way, it becomes clear whether the limitation was intentional or not.

[uros-b]

cc @szehon-ho PTAL

[szehon-ho]

Both changes are correct and behavior-preserving, and newArrayListWithCapacity is the right helper here since the sizes are exact rather than estimates.

For ManifestFiles.writeParallel there's a better version of the change: the list being pre-sized doesn't need to exist at all, and removing it would also bring the method in line with every other parallel fan-out in the codebase. Details inline.

[szehon-ho]

Merged, thanks @uros-b and @anoopj @ebyhr for additional review!