feat(shuffleV2): support multi-CN via serve-all-buckets mode

[aunjgr]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

issue #24097

What this PR does / why we need it:

Shuffle v2 (in-process ShufflePoolV2) was only used on single-CN because its Call() method only served the current worker's bucket. On multi-CN source scopes where Mcpu=1 (maxHolders==1), the single worker wrote rows to all N buckets but only drained bucket 0 — data for remote CNs was stranded in the pool.

Fix: When maxHolders == 1, Call() uses getAnyFullBatch() / getAnyLastBatch() to serve batches from all buckets. This lets the downstream Dispatch operator route each batch to the correct target CN based on ShuffleIDX.

Compile changes: The multi-CN constructor paths (constructShuffleOperatorForJoin and constructShuffleArgForGroup) now create v2 shuffle operators instead of v1. Single-CN paths (compileShuffleJoinV2 / compileShuffleGroupV2) are unchanged.

remoterun.go: Added vm.ShuffleV2 serialization/deserialization.

How scattering/gathering works:

Source CN (Mcpu=1):
  [child ops] -> [v2 Shuffle] -> [Dispatch]
                    |                 |
                    | set ShuffleIDX  | routes bat to register[ShuffleIDX]
                    | serve all N     |
                    | buckets         +- LocalRegs  -> PipelineSpool (same CN)
                    |                 +- RemoteRegs -> MoRPC (remote CN)

Target CN: MergeReceiver -> [HashJoin / Group]

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →