compute: select the arrange merge batcher by dyncfg

[antiguru]

Compute arrange sites could already choose between the columnation merge batcher and a columnar one, but only in the form of the paged batcher, so the columnation-versus-columnar comparison came entangled with the pager and its spill budget. This change separates the two axes. enable_columnar_merge_batcher selects the resident columnar batcher: the same Column chains and the same builder as the paged arm, merged through ColumnMerger, with no pager and no spill accounting. The columnation-versus-columnar question can now be measured on its own, and the paged arm becomes an increment on a columnar baseline rather than the only way to reach one.

The three type parameters mz_arrange_core takes are one unit rather than three independent knobs. Both the chunker's container and the builder's input are pinned to Batcher::Output, so the chunker and the builder follow from the batcher and each call site has to spell out a whole arm per variant. ArrangementBatcher in mz_compute::extensions::arrange names the three arms and resolves them from the config set in one place, so the two arrange sites, ArrangeBy in render::context and JoinStage in render::join::linear_join, no longer each encode the precedence rule. enable_column_paged_batcher keeps precedence, since it asks for the same columnar chains and additionally routes them through the pager, which leaves that flag's meaning and its rollout untouched.

Col2ValColBatcher in mz_timely_util::columnar is the new alias. It wraps ColumnMerger, which already existed and was exercised only by benchmarks, so this is the first production path through it. It reuses RowRowColPagedBuilder, whose Input is Column rather than PagedColumn and which therefore never depended on paging. The Paged in that builder's name records where it came from rather than a restriction, and its documentation now says so; the rename is left out of this change to keep the diff on the flag.

The flag is off in production and on in the CI configuration, so sqllogictest, testdrive, and the optimizer goldens exercise the columnar arm before it earns a production default. Parallel workload varies it alongside the paged flag. Only the two arrange sites named above are covered: logging arrangements are constructed before the replica's configuration is known and stay on the columnation batcher, and reduce, top-k, and threshold build batches through a builder with no merge batcher at all, so they have no arm to select.

Release notes: No user-facing changes.

🤖 Generated with Claude Code

[antiguru]

Thanks for the review!