Use Batcher to implement all of Arrange

[frankmcsherry]

arrange_core named three stages of one pipeline: a chunker that melds wire containers into sorted chunks, a batcher that merges chunks and carves by frontier, and a builder that seals a carved chain into a batch.
All three are a sorting batcher's internal strategy.
This PR hides the outer two, leaving Batcher as the only trait arrange knows about.

Chunker and Builder do not go away; they stop being public vocabulary.

The batcher seals its own batches — MergeBatcher carries the builder and seals internally, so extract returns a batch instead of a chain of chunks.
Sealing still happens at extraction with the whole chain in hand, so Builder::with_capacity still pre-sizes from the full key, value, and update counts.

\Batcher`'s time and output become associated types` — the input a batcher accepts stays a parameter; what it produces, and the timestamps it carves by, are facts about the batcher.

-pub trait Batcher<T, C0, C1> {
+pub trait Batcher<C0> {
+    type Time;
+    type Output;

The batcher chunks its own input — MergeBatcher holds the chunker, so insert takes the container from the wire and extract flushes before merging.
That removes the pre-seal drain loop from the operator, along with the comment explaining a seam arrange had no business knowing about.

Net effect on the signature:

-pub fn arrange_core<'scope, P, C, Chu, Ba, Bu, Tr>(
+pub fn arrange_core<'scope, P, C, Ba, Tr>(
-    Chu: ContainerBuilder + for<'a> PushInto<&'a mut C> + 'static,
-    Ba: Batcher<Tr::Time, Chu::Container, Vec<Bu::Input>> + 'static,
-    Bu: Builder<Time=Tr::Time, Output: Into<Tr::Batch>>,
+    Ba: Batcher<C, Time = Tr::Time, Output: Into<Tr::Batch>> + 'static,

One consequence worth flagging: MergeBatcher now implements Batcher<C> for every C its chunker accepts, and extract does not mention C, so a caller holding a concrete batcher must say which implementation it means.
Generic callers pin C in their bounds and are unaffected; the three sites needing a turbofish are tests driving a batcher by hand.
Stating that extraction is independent of the input type would mean putting extract on an un-parameterized supertrait, which seems worth revisiting only if a caller wants per-input extraction.

Builds warning-free, workspace tests pass.