[core] Reuse projected entries in manifest run merge

[leaves12138]

Follow-up to #9135 and #9213.

What changed

• Replace the hand-written manifest field indexes and custom projected-row materialization in run merge with ProjectedManifestEntry.ENTRY_LAYOUT_PROJECTION.
• Keep the shared PartitionDictionary unchanged and reuse it from the nested ManifestEntryRunMerge.SortPartitionDictionary, which only adds concurrent lookup and comparator ranks.
• Collect minor-compaction DELETE state per discovery task and combine it afterward instead of synchronizing every DELETE entry.
• Keep Avro file-name views borrowed for the current entry and copy only keys that outlive the row into reusable owned buffers.
• Add MAX_SEQUENCE_NUMBER to the shared entry layout because it is a row-id manifest sorting key.

Why

The run-merge implementation duplicated schema layout knowledge with numeric field constants and manual GenericRow projection. That made it easy for the optimized sort path to drift from the shared manifest representation and made schema changes require edits in multiple places. This follow-up routes the sort path through the same projected manifest abstraction used by block-aware ordinary merging while keeping sort-specific concurrency and ordering out of the common partition dictionary.

Validation

• Formatting and repository checks passed with ~/bin/check.
• Targeted manifest tests: 136 tests, 0 failures, 1 existing skip.
• Existing run-merge tests cover parallel discovery, partition ordering, secondary sorting keys, DELETE filtering, and external-sort equivalence.
• dev2 large-table metadata benchmark without an Xmx limit:

Snapshot	Before	After	Result
8795	5.26 s	4.96 s	no regression
8816	19.03 s	16.33 s	no regression

The output manifest counts and bytes remained unchanged in both benchmark cases.