Background
BatchMutationCall currently decides batching in add(), and each new task is only checked against the latest tail batch.
Problem
If one task is not batchable with the current batch, a new tail batch is created immediately.
Later tasks that could still be grouped with earlier compatible tasks are forced into later batches.
This causes fragmented batches, extra pipeline calls, and lower throughput under mixed key patterns.
The old batching flow also lacks an explicit version isolation step when assembling a batch.
Expected Behavior
Batching should maximize coalescing of compatible mutation tasks within the same execution window, even when non-batchable tasks are present in between.
Non-batchable tasks should not permanently fragment surrounding compatible tasks into separate executions.
Tasks from different range versions must always remain isolated to their own version-specific execution batches.
Under mixed traffic patterns, the scheduler should preserve correctness while reducing unnecessary pipeline invocations and improving overall batching efficiency.