MULTI/pipeline commands have no slotNumber, so a full-node slot migration can route the whole batch to the wrong node

[GiHoon1123]

Found while reviewing #3364.

_executeMulti/_executePipeline queue their commands without a slotNumber:

this._self.#queue.addCommand(args, { chainId, typeMapping })

extractCommandsForSlots(slots) (used for partial slot migrations) filters by
slotNumber, so these batch commands are never matched there — they just stay queued on
the original node, which is fine as long as that node is still alive.

But when a node loses all its slots, extractAllCommands() drains everything
regardless of slot, and cluster-slots.ts forwards the whole result to lastDestNode —
whichever destination happened to be processed last while walking the migration, not
necessarily the node that owns the batch's actual key slot. A MULTI/pipeline batch queued
at that point can end up sent to a node that doesn't own its slot, resulting in MOVED
errors or an aborted transaction instead of surviving the handoff.

Fixing this needs slot info preserved on batch-queued commands (or the full-node drain
routed per-command instead of to a single lastDestNode).

[nkaradzhov]

@GiHoon1123, thanks, confirmed. The cluster MULTI and pipeline executors drop the slot number, so batches are skipped by extractCommandsForSlots and forwarded to whichever destination was processed last. Only observable once #3364 lands, reach is limited to maintenance notifications with a batch queued during the window, and the failure is a visible error, so tracking as valid low priority. The fix should tag the whole chain with the routing key slot and only relocate fully queued chains.